All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Greg Kurz <groug@kaod.org>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	aik@ozlabs.ru, lvivier@redhat.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/4] ppc: add CPU IRQ state to PPC VMStateDescription
Date: Tue, 12 Sep 2017 17:21:01 +0100	[thread overview]
Message-ID: <20170912162100.GD2225@work-vm> (raw)
In-Reply-To: <20170911104854.GB2784@umbus.fritz.box>

* David Gibson (david@gibson.dropbear.id.au) wrote:
> On Mon, Sep 11, 2017 at 10:30:33AM +0100, Dr. David Alan Gilbert wrote:
> > * Greg Kurz (groug@kaod.org) wrote:
> > > On Sun, 10 Sep 2017 15:37:33 +0100
> > > Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
> > > 
> > > > Commit a90db15 "target-ppc: Convert ppc cpu savevm to VMStateDescription"
> > > > appears to drop the internal CPU IRQ state from the migration stream. Whilst
> > > > testing migration on g3beige/mac99 machines, test images would randomly fail to
> > > > resume unless a key was pressed on the VGA console.
> > > > 
> > > > Further investigation suggests that internal CPU IRQ state isn't being
> > > > preserved and so interrupts asserted at the time of migration are lost. Adding
> > > > the pending_interrupts and irq_input_state fields back into the migration
> > > > stream appears to fix the problem here during local tests.
> > > > 
> > > > As part of this commit we bump the vmstate_ppc version from 5 to 6 to handle
> > > > the additional fields.
> > > > 
> > > 
> > > And so this unconditionally breaks backward migration... what about adding
> > > a subsection for this ?
> > 
> > and wiring it to a flag on the machine type so that older machine types
> > don't send it.
> 
> Right, a subsection is certainly necessary to avoid breaking backwards
> migration.
> 
> But apart from that I want to understand better exactly why this is
> necessary.  What's the state that's being lost, and is it really not
> recoverable from anywhere else.
> 
> The other thing that concerns me is how we're encoding the
> information.  These are essentially internal fields, not reflecting
> something with an architected encoding - adding those to the migration
> stream is often a bad idea - it inhibits our ability to rework
> internal encodings.

Yes, agreed, where possible the contents of the stream should reflect
'real' state that's actually being modelled and be as independent of
the implementation as possible.

Dave

> > 
> > Dave
> > 
> > > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> > > > ---
> > > >  target/ppc/machine.c |    6 +++++-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> > > > index e59049f..8fec1a4 100644
> > > > --- a/target/ppc/machine.c
> > > > +++ b/target/ppc/machine.c
> > > > @@ -647,7 +647,7 @@ static const VMStateDescription vmstate_compat = {
> > > >  
> > > >  const VMStateDescription vmstate_ppc_cpu = {
> > > >      .name = "cpu",
> > > > -    .version_id = 5,
> > > > +    .version_id = 6,
> > > >      .minimum_version_id = 5,
> > > >      .minimum_version_id_old = 4,
> > > >      .load_state_old = cpu_load_old,
> > > > @@ -678,6 +678,10 @@ const VMStateDescription vmstate_ppc_cpu = {
> > > >          VMSTATE_UINTTL(env.hflags_nmsr, PowerPCCPU),
> > > >          /* FIXME: access_type? */
> > > >  
> > > > +        /* Interrupt state */
> > > > +        VMSTATE_UINT32_V(env.pending_interrupts, PowerPCCPU, 6),
> > > > +        VMSTATE_UINT32_V(env.irq_input_state, PowerPCCPU, 6),
> > > > +
> > > >          /* Sanity checking */
> > > >          VMSTATE_UINTTL_TEST(mig_msr_mask, PowerPCCPU, cpu_pre_2_8_migration),
> > > >          VMSTATE_UINT64_TEST(mig_insns_flags, PowerPCCPU, cpu_pre_2_8_migration),
> > > 
> > 
> > 
> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  parent reply	other threads:[~2017-09-12 16:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-10 14:37 [Qemu-devel] [PATCH 0/4] ppc: migration fixes for TCG Mark Cave-Ayland
2017-09-10 14:37 ` [Qemu-devel] [PATCH 1/4] ppc: change CPUPPCState access_type from int to uint8_t Mark Cave-Ayland
2017-09-10 16:30   ` Laurent Vivier
2017-09-10 18:00     ` Mark Cave-Ayland
2017-09-10 14:37 ` [Qemu-devel] [PATCH 2/4] ppc: add CPU IRQ state to PPC VMStateDescription Mark Cave-Ayland
2017-09-11  7:50   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-09-11  9:30     ` Dr. David Alan Gilbert
2017-09-11 10:48       ` David Gibson
2017-09-11 16:46         ` Mark Cave-Ayland
2017-09-11 17:19           ` Dr. David Alan Gilbert
2017-09-13  7:03             ` David Gibson
2017-09-12 16:21         ` Dr. David Alan Gilbert [this message]
2017-09-12 16:41           ` Mark Cave-Ayland
2017-09-12 16:46             ` Mark Cave-Ayland
2017-09-13  2:23               ` Alexey Kardashevskiy
2017-09-13  6:02                 ` David Gibson
2017-09-13 16:44                   ` Mark Cave-Ayland
2017-09-13 17:13                     ` Greg Kurz
2017-09-14  3:48                       ` David Gibson
2017-09-14  3:30                     ` David Gibson
2017-09-10 14:37 ` [Qemu-devel] [PATCH 3/4] ppc: add CPU access_type into the migration stream Mark Cave-Ayland
2017-09-11 10:57   ` David Gibson
2017-09-11 16:52     ` Mark Cave-Ayland
2017-09-13  7:19       ` David Gibson
2017-09-13 17:17         ` Mark Cave-Ayland
2017-09-14  3:54           ` David Gibson
2017-09-10 14:37 ` [Qemu-devel] [PATCH 4/4] ppc: ensure we update the decrementer value during migration Mark Cave-Ayland
2017-09-13  7:12   ` David Gibson
2017-09-13 17:11     ` Mark Cave-Ayland
2017-09-13 17:58       ` Laurent Vivier
2017-09-14  3:52         ` David Gibson
2017-09-15 12:45           ` Mark Cave-Ayland
2017-09-19  8:36             ` David Gibson

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=20170912162100.GD2225@work-vm \
    --to=dgilbert@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=lvivier@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.