[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, 27 Nov 2020 19:20:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 11/27/20 7:13 PM, Eduardo Habkost wrote:
> On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
>> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
>>> On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
>>>> add a new optional interface to CPUClass,
>>>> which allows accelerators to extend the CPUClass
>>>> with additional accelerator-specific initializations.
>>>>
>>>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>>>> ---
>>> [...]
>>>> +static void accel_init_cpu_int_aux(ObjectClass *klass, void *opaque)
>>>> +{
>>>> + CPUClass *cc = CPU_CLASS(klass);
>>>> + AccelCPUClass *accel_cpu_interface = opaque;
>>>> +
>>>> + cc->accel_cpu_interface = accel_cpu_interface;
>>>> + if (accel_cpu_interface->cpu_class_init) {
>>>> + accel_cpu_interface->cpu_class_init(cc);
>>>> + }
>>>> +}
>>>
>>> So, now that the approach we're following to trigger the
>>> accel_init_cpu*() call is less controversial (thanks for your
>>> patience!), we can try to address the monkey patching issue:
>>>
>>> Monkey patching classes like this is acceptable as an initial
>>> solution, but I'd like us to have a plan to eventually get rid of
>>> it. Monkey patching CPU classes makes querying of CPU model
>>> information less predictable and subtly dependent on QEMU
>>> initialization state.
>>
>>
>> The question of QEMU initialization state and the querying of supported
>> functionality, also in relationship with the loadable modules, is I think a
>> larger discussion.
>>
>> Regardless of the amount of glue code and lipstick, this is hiding the fact
>> that the fundamentals of the object hierarchy for cpus are wrong,
>> and are (unfortunately) codified as part of the external interface.
>
> That's probably right, and removal of monkey patching might force
> us to change our external interfaces.
>
>>
>>
>>>
>>> Removing CPUClass.accel_cpu_interface may be easy, because it
>>> should be possible to just call current_accel() when realizing
>>> CPUs. Getting rid of CPUClass.cpu_class_init might be more
>>> difficult, depending on what the ->cpu_class_init() function is
>>> doing.
>>
>>
>> This seems to be for a next step to me.
>
> Agreed, although I'd like to understand what makes
> AccelCPUClass.cpu_class_init() so important in the first version
> (considering that existing x86_cpu_class_init() has zero
> tcg_enabled() calls today).
>
currently x86_cpu_common_class_init() has
#ifdef CONFIG_TCG
and
#ifdef CONFIG_USER_ONLY
I move this code to a tcg specific module,
and I also move the parts that should have been CONFIG_TCG before but were
probably just missed.
Ciao,
Claudio
- [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, (continued)
- [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2020/11/26
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Paolo Bonzini, 2020/11/27
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2020/11/27
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2020/11/27
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2020/11/27
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Paolo Bonzini, 2020/11/27
- Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2020/11/27
Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass, Eduardo Habkost, 2020/11/27
[RFC v6 09/11] accel: replace struct CpusAccel with AccelOpsClass, Claudio Fontana, 2020/11/26
[RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2020/11/26
- Re: [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Eduardo Habkost, 2020/11/27
- Re: [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2020/11/27
- Re: [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Eduardo Habkost, 2020/11/27
- Re: [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2020/11/27
- Re: [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Eduardo Habkost, 2020/11/27