[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH RFC qom-cpu-next 0/6] QOM CPUState VM
From: |
Andreas Färber |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH RFC qom-cpu-next 0/6] QOM CPUState VMStateDescriptions |
Date: |
Thu, 07 Feb 2013 16:55:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 |
Am 02.02.2013 16:04, schrieb Andreas Färber:
> Hello,
>
> In response to patches from Juan [1], this series implements a declarative way
> for CPUs to register their CPU-specific VMStateDescription.
Ping? OK to go ahead with patches 1-3? Any thoughts on how to proceed
with the not-yet-migratable targets? Juan? Anthony?
Thanks,
Andreas
> There are subtle differences between CPU and devices in how they register
> their savevm handlers and VMStateDescription respectively:
>
> * CPUs register one VMStateDescription "cpu_common" plus savevm handlers for
> the target-specifics (machine.c:cpu_{save,load}).
> Devices register one VMStateDescription with a subsection for common state
> where necessary.
>
> * CPUs use their cpu_index field as instance_id.
> Devices pass -1 as instance_id, resulting in highest index on the bus plus
> 1.
> Note: The current cpu_index numbering is not hot-unplug-safe.
>
> My code assumes that registering "cpu_common" for CPUArchState (until changed
> in CPUState part 9 series) while registering "cpu" for CPUState is compatible,
> since by not using DeviceState::vmsd infrastructure registration order remains
> guaranteed the same.
>
> Patches 4-5 demonstrate how two VMStateDescription-prepared but not yet
> migratable targets would look like if we want to adopt a consistent pattern
> for VMStateDescription registration and layout throughout targets.
>
> Question is whether we want to take that legacy burden on us or whether to
> simply expose exec.c:vmstate_cpu_common and embed it PCI-like into the
> prepared VMStateDescriptions for alpha and openrisc and register them through
> DeviceClass::vmsd instead.
>
> An alternative might be registering "cpu_common" as before but with
> instance_id -1 and registering "cpu" through DeviceClass::vmsd, since
> exec.c:calculate_new_instance_id() takes the name string into account.
> But that would be inconsistent with how devices behave VMState-wise.
>
> Targets that have not yet been converted to VMState [1, 2] are left untouched.
>
> Known conflicts:
> - CPUState part 9 v1 series (target-*/cpu.c:class_init), to be rebased on
> this.
>
> Available for testing here:
> git://github.com/afaerber/qemu-cpu.git qom-cpu-vmstate.v1
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-vmstate.v1
>
> What triggered this series was moving the halted and interrupt_request fields
> from CPU_COMMON to CPUState:
> https://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg00203.html
> Since both are in vmstate_cpu_common, they needed to be moved together, and
> "cpu_common" will need to operate on CPUState then. At the same time x86
> can no longer access the halted field from CPUX86State via VMSTATE_ macros,
> so either we need to drop uses of such fields (i.e., version 5) or make it
> possible to access CPUState fields in x86 VMState through parent_obj field.
> Further, in explaining intended uses of S390CPU vs. CPUS390XState I was
> reminded that VMState is currently a limiting factor for placing fields into
> CPUState-derived types rather than into CPU*State.
>
> Regards,
> Andreas
>
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg00524.html
> [2] https://lists.nongnu.org/archive/html/qemu-devel/2012-09/msg03451.html
>
> Cc: Juan Quintela <address@hidden>
> Cc: Michael Roth <address@hidden>
>
> Cc: Anthony Liguori <address@hidden>
> Cc: Blue Swirl <address@hidden>
> Cc: Aurélien Jarno <address@hidden>
>
> Cc: Eduardo Habkost <address@hidden>
> Cc: Igor Mammedov <address@hidden>
> Cc: Richard Henderson <address@hidden>
> Cc: Michael Walle <address@hidden>
> Cc: Jia Liu <address@hidden>
>
> Cc: David Gibson <address@hidden>
> Cc: Alexander Graf <address@hidden>
> Cc: address@hidden
>
> Andreas Färber (6):
> cpu: Register VMStateDescription through CPUState
> target-i386: Update VMStateDescription to X86CPU
> target-lm32: Update VMStateDescription to LM32CPU
> target-alpha: Register VMStateDescription for AlphaCPU
> target-openrisc: Register VMStateDescription for OpenRISCCPU
> cpu: Guard cpu_{save,load}() definitions
>
> exec.c | 13 ++-
> include/qemu-common.h | 2 +
> include/qom/cpu.h | 3 +
> target-alpha/cpu-qom.h | 2 +
> target-alpha/cpu.c | 3 +
> target-alpha/machine.c | 64 ++++++--------
> target-i386/cpu-qom.h | 2 +
> target-i386/cpu.c | 4 +
> target-i386/cpu.h | 2 -
> target-i386/machine.c | 215
> ++++++++++++++++++++++-----------------------
> target-lm32/cpu-qom.h | 2 +
> target-lm32/cpu.c | 4 +
> target-lm32/cpu.h | 2 -
> target-lm32/machine.c | 36 +++-----
> target-openrisc/cpu.c | 3 +
> target-openrisc/cpu.h | 2 +
> target-openrisc/machine.c | 33 +++----
> 17 Dateien geändert, 200 Zeilen hinzugefügt(+), 192 Zeilen entfernt(-)
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg