[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass
From: |
Claudio Fontana |
Subject: |
Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass |
Date: |
Fri, 18 Dec 2020 23:30:54 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
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?
Ciao,
CLaudio