[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass
From: |
Alex Bennée |
Subject: |
Re: [PATCH v14 18/22] accel: introduce AccelCPUClass extending CPUClass |
Date: |
Thu, 28 Jan 2021 16:08:48 +0000 |
User-agent: |
mu4e 1.5.7; emacs 28.0.50 |
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?
The bool returning realizefn with Error is a fairly common pattern.
>
>>
>>> +} AccelCPUClass;
>>
>>
>
> Thanks for looking at this,
>
> Claudio
--
Alex Bennée
- [PATCH v14 10/22] cpu: move cc->transaction_failed to tcg_ops, (continued)
- [PATCH v14 10/22] cpu: move cc->transaction_failed to tcg_ops, Claudio Fontana, 2021/01/28
- [PATCH v14 12/22] physmem: make watchpoint checking code TCG-only, Claudio Fontana, 2021/01/28
- [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 <=
- 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, 2021/01/30
- 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