From: "Andreas Färber" <afaerber@suse.de>
To: qemu-devel@nongnu.org
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
quintela@redhat.com, "Jia Liu" <proljc@gmail.com>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
"Alexander Graf" <agraf@suse.de>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Michael Walle" <michael@walle.cc>,
qemu-ppc@nongnu.org, "Anthony Liguori" <anthony@codemonkey.ws>,
"Igor Mammedov" <imammedo@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Andreas Färber" <afaerber@suse.de>,
"Aurélien Jarno" <aurelien@aurel32.net>,
"Richard Henderson" <rth@twiddle.net>
Subject: [Qemu-devel] [PATCH RFC qom-cpu-next 0/6] QOM CPUState VMStateDescriptions
Date: Sat, 2 Feb 2013 16:04:10 +0100 [thread overview]
Message-ID: <1359817456-25561-1-git-send-email-afaerber@suse.de> (raw)
Hello,
In response to patches from Juan [1], this series implements a declarative way
for CPUs to register their CPU-specific VMStateDescription.
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 <quintela@redhat.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: Aurélien Jarno <aurelien@aurel32.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Michael Walle <michael@walle.cc>
Cc: Jia Liu <proljc@gmail.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org
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(-)
--
1.7.10.4
next reply other threads:[~2013-02-02 15:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-02 15:04 Andreas Färber [this message]
2013-02-02 15:04 ` [Qemu-devel] [PATCH RFC qom-cpu-next 1/6] cpu: Register VMStateDescription through CPUState Andreas Färber
2013-02-02 15:04 ` [Qemu-devel] [PATCH RFC qom-cpu-next 2/6] target-i386: Update VMStateDescription to X86CPU Andreas Färber
2013-02-02 15:04 ` [Qemu-devel] [PATCH RFC qom-cpu-next 3/6] target-lm32: Update VMStateDescription to LM32CPU Andreas Färber
2013-02-02 15:04 ` [Qemu-devel] [RFC qom-cpu-next 4/6] target-alpha: Register VMStateDescription for AlphaCPU Andreas Färber
2013-02-02 15:04 ` [Qemu-devel] [RFC qom-cpu-next 5/6] target-openrisc: Register VMStateDescription for OpenRISCCPU Andreas Färber
2013-02-02 15:04 ` [Qemu-devel] [RFC qom-cpu-next 6/6] cpu: Guard cpu_{save, load}() definitions Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1359817456-25561-1-git-send-email-afaerber@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=anthony@codemonkey.ws \
--cc=aurelien@aurel32.net \
--cc=blauwirbel@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=michael@walle.cc \
--cc=proljc@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).