From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Thomas Huth <thuth@linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>,
David Hildenbrand <dahi@linux.vnet.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
"Jason J. Herne" <jjherne@us.ibm.com>,
Andreas Faerber <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PULL 7/8] s390x/migration: migrate CPU state
Date: Thu, 9 Oct 2014 19:32:02 +0200 [thread overview]
Message-ID: <20141009193202.3a1925d6.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <CAFEAcA8VRBuRXLi9cr+OCg47H2CDJVmAwMx49BT0EvUbdZZ9yw@mail.gmail.com>
On Thu, 9 Oct 2014 17:28:57 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:
> On 9 October 2014 14:36, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> > From: Thomas Huth <thuth@linux.vnet.ibm.com>
> >
> > This patch provides the cpu save information for dumps and later life
> > migration and enables migration of the CPU state. The code is based on
> > earlier work from Christian Borntraeger and Jason Herne.
> >
> > Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> > Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
> > [provide cpu_post_load()]
> > Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
> > CC: Andreas Faerber <afaerber@suse.de>
> > CC: Christian Borntraeger <borntraeger@de.ibm.com>
> > CC: Jason J. Herne <jjherne@us.ibm.com>
> > Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > ---
> > target-s390x/cpu.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 57 insertions(+), 2 deletions(-)
> >
> > diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
> > index ec7df90..c9c237f 100644
> > --- a/target-s390x/cpu.c
> > +++ b/target-s390x/cpu.c
>
> I think the migration code should live in machine.c like
> it does for our other targets. (Among other useful things,
> this means you can have the makefile say
> obj-$(CONFIG_SOFTMMU) += machine.o
> so it doesn't try to build it for the linux-user target :-))
Probably. Thomas, can you look into that (and the other comments)?
>
> > @@ -292,9 +292,64 @@ unsigned int s390_cpu_set_state(uint8_t cpu_state, S390CPU *cpu)
> > }
> > #endif
> >
> > +static int cpu_post_load(void *opaque, int version_id)
> > +{
> > + S390CPU *cpu = opaque;
> > +
> > + /* the cpu state is fine for QEMU - we just need to push it to kvm */
> > + if (kvm_enabled()) {
> > + kvm_s390_set_cpu_state(cpu, cpu->env.cpu_state);
> > + }
>
> Haven't looked at the detail but I'm vaguely surprised
> this has to be done manually rather than it just
> being automatically resynced when we next try to
> run the vCPU.
We also need to propagate state to vcpus that have not been yet run, as
code targeting other vcpus may need to check it.
>
> > +
> > + return 0;
> > +}
> > +
> > static const VMStateDescription vmstate_s390_cpu = {
> > .name = "cpu",
> > - .unmigratable = 1,
> > + .post_load = cpu_post_load,
> > + .version_id = 1,
> > + .minimum_version_id = 1,
> > + .minimum_version_id_old = 1,
>
> You don't need minimum_version_id_old any more.
>
> > + .fields = (VMStateField[]) {
> > + VMSTATE_UINT64(env.fregs[0].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[1].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[2].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[3].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[4].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[5].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[6].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[7].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[8].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[9].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[10].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[11].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[12].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[13].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[14].ll, S390CPU),
> > + VMSTATE_UINT64(env.fregs[15].ll, S390CPU),
> > + VMSTATE_UINT64_ARRAY(env.regs, S390CPU, 16),
> > + VMSTATE_UINT64(env.psw.mask, S390CPU),
> > + VMSTATE_UINT64(env.psw.addr, S390CPU),
> > + VMSTATE_UINT64(env.psa, S390CPU),
> > + VMSTATE_UINT32(env.fpc, S390CPU),
> > + VMSTATE_UINT32(env.todpr, S390CPU),
> > + VMSTATE_UINT64(env.pfault_token, S390CPU),
> > + VMSTATE_UINT64(env.pfault_compare, S390CPU),
> > + VMSTATE_UINT64(env.pfault_select, S390CPU),
> > + VMSTATE_UINT64(env.cputm, S390CPU),
> > + VMSTATE_UINT64(env.ckc, S390CPU),
> > + VMSTATE_UINT64(env.gbea, S390CPU),
> > + VMSTATE_UINT64(env.pp, S390CPU),
> > + VMSTATE_UINT32_ARRAY(env.aregs, S390CPU, 16),
> > + VMSTATE_UINT64_ARRAY(env.cregs, S390CPU, 16),
> > + VMSTATE_UINT8(env.cpu_state, S390CPU),
> > + VMSTATE_END_OF_LIST()
> > + },
> > + .subsections = (VMStateSubsection[]) {
> > + {
> > + /* empty */
> > + }
>
> Why the empty subsections list?
>
> > + }
> > };
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2014-10-09 17:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 13:35 [Qemu-devel] [PULL 0/8] s390x patches for 2.2 Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 1/8] linux-headers: update to 3.17-rc7 Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 2/8] s390x/kvm: introduce proper states for s390 cpus Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 3/8] s390x/kvm: proper use of the cpu states OPERATING and STOPPED Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 4/8] s390x/kvm: propagate s390 cpu state to kvm Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 5/8] s390x/kvm: reuse kvm_s390_reset_vcpu() to get rid of ifdefs Cornelia Huck
2014-10-09 13:35 ` [Qemu-devel] [PULL 6/8] s390x/kvm: synchronize the cpu state after SIGP (INITIAL) CPU RESET Cornelia Huck
2014-10-09 13:36 ` [Qemu-devel] [PULL 7/8] s390x/migration: migrate CPU state Cornelia Huck
2014-10-09 16:28 ` Peter Maydell
2014-10-09 17:32 ` Cornelia Huck [this message]
2014-10-10 7:08 ` Thomas Huth
2014-10-09 13:36 ` [Qemu-devel] [PULL 8/8] s390x/virtio-ccw: fix vhost-scsi intialization Cornelia Huck
2014-10-09 16:22 ` [Qemu-devel] [PULL 0/8] s390x patches for 2.2 Peter Maydell
2014-10-09 17:18 ` Cornelia Huck
2014-10-09 17:23 ` Peter Maydell
2014-10-09 17:43 ` Cornelia Huck
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=20141009193202.3a1925d6.cornelia.huck@de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=jjherne@us.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@linux.vnet.ibm.com \
/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).