From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <groug@kaod.org>
Cc: aik@au1.ibm.com, qemu-devel@nongnu.org, paulus@ozlabs.org,
qemu-ppc@nongnu.org,
Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v9 6/6] migration: Include migration support for machine check handling
Date: Fri, 7 Jun 2019 10:22:40 +1000 [thread overview]
Message-ID: <20190607002240.GD3760@umbus.fritz.box> (raw)
In-Reply-To: <20190606141048.01e7d6be@bahia.lab.toulouse-stg.fr.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3276 bytes --]
On Thu, Jun 06, 2019 at 02:10:48PM +0200, Greg Kurz wrote:
> On Thu, 6 Jun 2019 16:45:30 +0530
> Aravinda Prasad <aravinda@linux.vnet.ibm.com> wrote:
>
> > On Thursday 06 June 2019 11:36 AM, Greg Kurz wrote:
> > > On Thu, 6 Jun 2019 13:06:14 +1000
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > >> On Wed, May 29, 2019 at 11:10:57AM +0530, Aravinda Prasad wrote:
> > >>> This patch includes migration support for machine check
> > >>> handling. Especially this patch blocks VM migration
> > >>> requests until the machine check error handling is
> > >>> complete as (i) these errors are specific to the source
> > >>> hardware and is irrelevant on the target hardware,
> > >>> (ii) these errors cause data corruption and should
> > >>> be handled before migration.
> > >>>
> > >>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> > >>> ---
> > >>> hw/ppc/spapr.c | 20 ++++++++++++++++++++
> > >>> hw/ppc/spapr_events.c | 17 +++++++++++++++++
> > >>> hw/ppc/spapr_rtas.c | 4 ++++
> > >>> include/hw/ppc/spapr.h | 2 ++
> > >>> 4 files changed, 43 insertions(+)
> > >>>
> > >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > >>> index e8a77636..31c4850 100644
> > >>> --- a/hw/ppc/spapr.c
> > >>> +++ b/hw/ppc/spapr.c
> > >>> @@ -2104,6 +2104,25 @@ static const VMStateDescription vmstate_spapr_dtb = {
> > >>> },
> > >>> };
> > >>>
> > >>> +static bool spapr_fwnmi_needed(void *opaque)
> > >>> +{
> > >>> + SpaprMachineState *spapr = (SpaprMachineState *)opaque;
> > >>> +
> > >>> + return (spapr->guest_machine_check_addr == -1) ? 0 : 1;
> > >>
> > >> Since we're introducing a PAPR capability to enable this, it would
> > >> actually be better to check that here, rather than the runtime state.
> > >> That leads to less cases and easier to understand semantics for the
> > >> migration stream.
> > >>
> > >
> > > Hmmm... the purpose of needed() VMState callbacks is precisely about
> > > runtime state: the subsection should only be migrated if an MCE is
> > > pending, ie. spapr->guest_machine_check_addr != -1.
> >
> > spapr->guest_machine_check_addr is set when fwnmi is registered. Hence
> > an MCE might not be pending if it is set.
> >
>
> Oops sorry, got confused... should have written "if the guest has
> registered FWNMI", but the idea is the same. We only need to migrate
> the subsection if the state is different from reset. This is the way
> needed() callbacks are generally implemented.
Yes, but usually that's because we need to omit the section if it's
not actively in use in order to maintain backwards compatiblity with
old migration streams. If the cap is enabled we already need
something that implements it at both ends to have a sane migration.
> > I am fine with both the approaches (checking for
> > guest_machine_check_addr or for SPAPR_CAP_FWNMI_MCE).
> >
>
> I would find ackward to migrate this always for new machine types,
> even if the guest doesn't register FWNMI...
How so?
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-06-07 0:42 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 5:40 [Qemu-devel] [PATCH v9 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests Aravinda Prasad
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 1/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls Aravinda Prasad
2019-06-03 10:12 ` Greg Kurz
2019-06-03 11:17 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-06-04 6:08 ` Aravinda Prasad
2019-06-04 14:50 ` Greg Kurz
2019-06-06 5:17 ` Aravinda Prasad
2019-06-06 1:35 ` David Gibson
2019-06-06 4:39 ` Aravinda Prasad
2019-06-06 1:34 ` [Qemu-devel] " David Gibson
2019-06-06 5:26 ` [Qemu-devel] [Qemu-ppc] " Aravinda Prasad
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 2/6] Wrapper function to wait on condition for the main loop mutex Aravinda Prasad
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 3/6] target/ppc: Handle NMI guest exit Aravinda Prasad
2019-06-03 11:53 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-06-06 1:43 ` [Qemu-devel] " David Gibson
2019-06-06 4:45 ` Aravinda Prasad
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 4/6] target/ppc: Build rtas error log upon an MCE Aravinda Prasad
2019-06-03 14:00 ` Greg Kurz
2019-06-04 6:29 ` Aravinda Prasad
2019-06-04 9:01 ` Greg Kurz
2019-06-04 10:10 ` [Qemu-devel] [Qemu-ppc] " Aravinda Prasad
2019-06-06 2:58 ` [Qemu-devel] " David Gibson
2019-06-06 2:57 ` David Gibson
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 5/6] ppc: spapr: Enable FWNMI capability Aravinda Prasad
2019-06-03 15:25 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-06-04 6:45 ` Aravinda Prasad
2019-06-06 3:02 ` David Gibson
2019-06-06 4:50 ` Aravinda Prasad
2019-06-06 7:51 ` Aravinda Prasad
2019-06-06 3:00 ` [Qemu-devel] " David Gibson
2019-05-29 5:40 ` [Qemu-devel] [PATCH v9 6/6] migration: Include migration support for machine check handling Aravinda Prasad
2019-06-03 15:40 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-06-04 7:04 ` Aravinda Prasad
2019-06-04 20:04 ` Greg Kurz
2019-06-04 20:11 ` Greg Kurz
2019-06-06 3:06 ` [Qemu-devel] " David Gibson
2019-06-06 6:06 ` Greg Kurz
2019-06-06 11:15 ` Aravinda Prasad
2019-06-06 12:10 ` Greg Kurz
2019-06-07 0:22 ` David Gibson [this message]
2019-06-07 10:30 ` Greg Kurz
2019-06-06 11:25 ` Aravinda Prasad
2019-06-06 12:24 ` Greg Kurz
2019-06-07 0:23 ` 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=20190607002240.GD3760@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@au1.ibm.com \
--cc=aravinda@linux.vnet.ibm.com \
--cc=groug@kaod.org \
--cc=paulus@ozlabs.org \
--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 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).