qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC qom-cpu-next 0/6] QOM CPUState VMStateDescri


From: Andreas Färber
Subject: Re: [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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]