+Juan
On 4/22/21 12:03 AM, Eduardo Habkost wrote:
> On Tue, Mar 02, 2021 at 03:57:52PM +0100, Philippe Mathieu-Daudé wrote:
>> The cpu model is the single device available in user-mode.
>> Since we want to restrict some fields to user-mode emulation,
>> we prefer to set the vmsd field of CPUClass, rather than the
>> DeviceClass one.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org>
>
> Is this going to have an externally visible effect?
On system emulation, no, because unchanged.
On user emulation migration it is not used, the symbol is here
to satisfy linking:
include/hw/core/cpu.h-1070-#ifdef CONFIG_SOFTMMU
include/hw/core/cpu.h-1071-extern const VMStateDescription
vmstate_cpu_common;
include/hw/core/cpu.h-1072-#else
include/hw/core/cpu.h:1073:#define vmstate_cpu_common vmstate_dummy
include/hw/core/cpu.h-1074-#endif
include/migration/vmstate.h:197:extern const VMStateDescription
vmstate_dummy;
stubs/vmstate.c:4:const VMStateDescription vmstate_dummy = {};
> If it does, how can we make sure it's safe?
>
> If it does not, do you know why CPUClass::vmsd exists in the
> first place?
My guess is CPUState is the only device used in user emulation,
so it would be a way to restrict the vmstate_dummy to CPU and
not to any DeviceState?
But looking at the introductory commit:
commit b170fce3dd06372f7bfec9a780ebcb1fce6d57e4
Author: Andreas Färber <afaer...@suse.de>
Date: Sun Jan 20 20:23:22 2013 +0100
cpu: Register VMStateDescription through CPUState
In comparison to DeviceClass::vmsd, CPU VMState is split in two,
"cpu_common" and "cpu", and uses cpu_index as instance_id instead of -1.
Therefore add a CPU-specific CPUClass::vmsd field.
Unlike the legacy CPUArchState registration, rather register CPUState.
Juan, do you remember?
>
> Do you think it would be simpler to just squash this patch into
> [PATCH v3 08/27] cpu: Move CPUClass::vmsd to SysemuCPUOps
> ?
Certainly cleaner, I'll respin!
Thanks,
Phil.
