On 12/18/20 7:01 PM, Paolo Bonzini wrote:
> On 18/12/20 18:51, Claudio Fontana wrote:
>> But with things like cris/ for example,
>> the tcg functions to use are actually versioned per each subclass of
>> TYPE_CRIS_CPU.
>>
>> Different tcg_ops need to be used for different subclasses of the
>> CPU_RESOLVING_TYPE.
>
> CRIS is not that bad since it's TCG only. You can just make it a field
> in CRISCPUClass and copy it over to tcg_ops.
>
> I think ARM had something similar though, with different do_interrupt
> implementations for M and A processors. Somebody from Linaro was
> cleaning it up as part of some BQL work, but it was never merged. But
> even in that case, do_interrupt is somewhat special for ARM so making it
> an xxxCPUClass field makes sense.
>
> Paolo
Ok that's a good alternative,
>
>> So in order to avoid code in the class initialization like this:
>>
>> if (version1) { then set the tcg ops for version 1; }
>> if (version2) { then set the tcg ops for version 2; ...} etc,
>>
>> we could define the right tcg op variants corresponding to the cpu variants,
>> so that everything can be matched automatically.
>>
>> But I think we'd need to pass explicitly the cpu type in
>> accel_init_cpu_interfaces for this to work..
>> we could still in the future call accel_init_cpu_interfaces multiple times,
>> once for each cpu model we want to use.
>>
>> Or, we could do something else: we could delay the accel cpu interface
>> initialization and call it in cpu_create(const char *typename),
>> where typename needs to be known for sure.
I take you don't like this idea to initialize the accel cpu interface in
cpu_create()?
It seems to make sense to me, but any drawbacks?
Ciao thanks!
Claudio
>>
>> This last option seems kinda attractive, but any ideas?
