Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass

[Claudio Fontana]

On 12/18/20 7:04 PM, Claudio Fontana wrote:
> 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?
> 
> 

Oh I see, sadly, only user mode code seem to be guaranteed to go through 
cpu_create(), so there is probably no single code point,
where we are guaranteed to see the creation of a cpu, everything is duplicated 
with explict calls to object_new in multiple places.

Hmm...

Ciao,

Claudio