On 12/18/20 11:30 PM, Claudio Fontana wrote:
> On 12/18/20 10:55 PM, Claudio Fontana wrote:
>> 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...
>
> Well we can actually do it in the right place, that is in cpu_common_intfn,
> by calling accel_init_cpu_intefaces there, which kinda makes sense anyway...
> wdyt?
>
But then the mapping becomes difficult.. actually I think we/I need to study
carefully all targets to figure out the best way to associate a cpu
subclass/model with its accel cpu interface.
it's going to be next year now.
Happy holidays,
Claudio
