[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 01/27] target: Set CPUClass::vmsd instead of DeviceClass::
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v3 01/27] target: Set CPUClass::vmsd instead of DeviceClass::vmsd |
Date: |
Thu, 22 Apr 2021 13:01:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
On 4/22/21 12:28 PM, Peter Maydell wrote:
> On Thu, 22 Apr 2021 at 10:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> 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 <afaerber@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?
>
> Oh yes, I remember this. There are two ways to handle migration for
> a CPU object:
>
> (1) like any other device, so it has a dc->vmsd that covers
> migration for the whole object. As usual for objects that are a
> subclass of a parent that has state, the first entry in the
> VMStateDescription field list is VMSTATE_CPU(), which migrates
> the cpu_common fields, followed by whatever the CPU's own migration
> fields are.
> (2) a backwards-compatible mechanism for CPUs that were
> originally migrated using manual "write fields to the migration
> stream structures". The on-the-wire migration format
> for those is based on the 'env' pointer (which isn't a QOM object),
> and the cpu_common part of the migration data is elsewhere.
>
> cpu_exec_realizefn() handles both possibilities:
> * for type 1, dc->vmsd is set and cc->vmsd is not,
> so cpu_exec_realizefn() does nothing, and the standard
> "register dc->vmsd for a device" code does everything needed
> * for type 2, dc->vmsd is NULL and so we register the vmstate_cpu_common
> directly to handle the cpu-common fields, and the cc->vmsd to handle
> the per-CPU stuff
>
> You can't change a CPU from one type to the other without breaking
> migration compatibility, which is why some guest architectures
> are stuck on the cc->vmsd form. New targets should use dc->vmsd.
Doh I just post v5. I guess I'll have to revisit patch #7, because
I likely blew type 2 migration:
20210422104705.2454166-1-f4bug@amsat.org/20210422104705.2454166-8-f4bug@amsat.org/">https://patchew.org/QEMU/20210422104705.2454166-1-f4bug@amsat.org/20210422104705.2454166-8-f4bug@amsat.org/