[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass
From: |
Claudio Fontana |
Subject: |
Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass |
Date: |
Sat, 30 Jan 2021 11:53:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 1/29/21 1:13 AM, Richard Henderson wrote:
> On 1/28/21 6:29 AM, Philippe Mathieu-Daudé wrote:
>> On 1/28/21 5:08 PM, Alex Bennée wrote:
>>>
>>> Claudio Fontana <cfontana@suse.de> writes:
>>>
>>>> On 1/28/21 2:03 PM, Philippe Mathieu-Daudé wrote:
>>>>> On 1/28/21 10:28 AM, Claudio Fontana wrote:
>>> <snip>
>>>>>> +
>>>>>> +#define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
>>>>>> +#define ACCEL_CPU_NAME(name) (name "-" TYPE_ACCEL_CPU)
>>>>>> +typedef struct AccelCPUClass AccelCPUClass;
>>>>>> +DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
>>>>>> +
>>>>>> +typedef struct AccelCPUClass {
>>>>>> + /*< private >*/
>>>>>> + ObjectClass parent_class;
>>>>>> + /*< public >*/
>>>>>> +
>>>>>> + void (*cpu_class_init)(CPUClass *cc);
>>>>>> + void (*cpu_instance_init)(CPUState *cpu);
>>>>>> + void (*cpu_realizefn)(CPUState *cpu, Error **errp);
>>>>>
>>>>> If we want callers to check errp, better have the prototype return
>>>>> a boolean.
>>>>
>>>> Good point, the whole errp thing is worth revisiting in the series,
>>>> there are many cases (which are basically reproduced in the refactoring
>>>> from existing code),
>>>> where errp is passed but is really unused.
>>>>
>>>> I am constantly internally debating whether to remove the parameter
>>>> altogether, or to keep it in there.
>>>>
>>>> What would you suggest?
>>>
>>> I think it really depends on if we can expect the realizefn to usefully
>>> return an error message that can be read and understood by the user. I
>>> guess this comes down to how much user config is going to be checked at
>>> the point we realize the CPU?
>>
>> cpu_realize() is were various feature checks are, isn't it?
>>
>> -cpu mycpu,feat1=on,feat2=off
>> CPU 'mycpu' can not disable feature 'feat2' because of REASON.
>
> Yes. And while changing the return type of realize is probably a good idea,
> it
> should be a separate patch.
>
>
> r~
>
To summarize:
1) accel->cpu_realizefn extends the current cpu target-specific realize
functions with accelerator-specific code,
which currently does not make use of errp at all (thus, the temptation to
remove errp from the interface until it is actually needed by a target).
2) Regarding the target-specific cpu realize functions themselves, registered
with the pattern:
device_class_set_parent_realize(dc, x86_cpu_realizefn, &xcc->parent_realize);
device_class_set_parent_realize(dc, arm_cpu_realizefn, &acc->parent_realize);
... etc ...
these currently all return void, and the code that realizes devices (f.e. in
hw/core/qdev.c)
calls these callbacks like this:
static void device_set_realized(...)
{
...
if (dc->realize) {
dc->realize(dev, &local_err);
if (local_err != NULL) {
goto fail;
}
}
Ie it does not expect a bool return type for realize().
So making realize return bool means changing all the realize functions for
all devices in my view,
which I don't think should be crammed in here..
Wdty?
Thanks,
Claudio
- [PATCH v14 11/22] cpu: move do_unaligned_access to tcg_ops, (continued)
- [PATCH v14 11/22] cpu: move do_unaligned_access to tcg_ops, Claudio Fontana, 2021/01/28
- [PATCH v14 14/22] cpu: move debug_check_watchpoint to tcg_ops, Claudio Fontana, 2021/01/28
- [PATCH v14 09/22] cpu: move cc->do_interrupt to tcg_ops, Claudio Fontana, 2021/01/28
- [PATCH v14 16/22] accel: extend AccelState and AccelClass to user-mode, Claudio Fontana, 2021/01/28
- [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Philippe Mathieu-Daudé, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Alex Bennée, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Philippe Mathieu-Daudé, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Richard Henderson, 2021/01/28
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass,
Claudio Fontana <=
- Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass, Richard Henderson, 2021/01/30
[PATCH v14 13/22] cpu: move adjust_watchpoint_address to tcg_ops, Claudio Fontana, 2021/01/28
[PATCH v14 21/22] hw/core/cpu: call qemu_init_vcpu in cpu_common_realizefn, Claudio Fontana, 2021/01/28
[PATCH v14 22/22] accel: introduce new accessor functions, Claudio Fontana, 2021/01/28
[PATCH v14 19/22] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2021/01/28
[PATCH v14 17/22] accel: replace struct CpusAccel with AccelOpsClass, Claudio Fontana, 2021/01/28
[PATCH v14 20/22] cpu: call AccelCPUClass::cpu_realizefn in cpu_exec_realizefn, Claudio Fontana, 2021/01/28
[PATCH v14 15/22] cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClass, Claudio Fontana, 2021/01/28