All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Axtens <dja@axtens.net>
Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>,
	paulus@ozlabs.org, linuxppc-dev@ozlabs.org,
	kvm-ppc@vger.kernel.org, mahesh@linux.vnet.ibm.com,
	agraf@suse.de, michaele@au1.ibm.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Exit guest upon fatal machine check exception
Date: Thu, 12 Nov 2015 14:38:16 +1100	[thread overview]
Message-ID: <20151112033816.GJ5852@voom.redhat.com> (raw)
In-Reply-To: <876118ymy4.fsf@gamma.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

On Thu, Nov 12, 2015 at 01:24:19PM +1100, Daniel Axtens wrote:
> Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes:
> 
> > This patch modifies KVM to cause a guest exit with
> > KVM_EXIT_NMI instead of immediately delivering a 0x200
> > interrupt to guest upon machine check exception in
> > guest address. Exiting the guest enables QEMU to build
> > error log and deliver machine check exception to guest
> > OS (either via guest OS registered machine check
> > handler or via 0x200 guest OS interrupt vector).
> >
> > This approach simplifies the delivering of machine
> > check exception to guest OS compared to the earlier approach
> > of KVM directly invoking 0x200 guest interrupt vector.
> > In the earlier approach QEMU patched the 0x200 interrupt
> > vector during boot. The patched code at 0x200 issued a
> > private hcall to pass the control to QEMU to build the
> > error log.
> >
> > This design/approach is based on the feedback for the
> > QEMU patches to handle machine check exception. Details
> > of earlier approach of handling machine check exception
> > in QEMU and related discussions can be found at:
> >
> > https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00813.html
> 
> I've poked at the MCE code, but not the KVM MCE code, so I may be
> mistaken here, but I'm not clear on how this handles errors that the
> guest can recover without terminating.
> 
> For example, a Linux guest can handle a UE in guest userspace by killing
> the guest process. A hypthetical non-linux guest with a microkernel
> could even survive UEs in drivers.
> 
> It sounds from your patch like you're changing this behaviour. Is this
> right?

So, IIUC.  Once the qemu pieces are in place as well it shouldn't
change this behaviour: KVM will exit to qemu, qemu will log the error
information (new), then reinject the MC to the guest which can still
handle it as you describe above.

But, there could be a problem if you have a new kernel with an old
qemu, in that case qemu might not understand the new exit type and
treat it as a fatal error, even though the guest could actually cope
with it.

Aravinda, do we need to change this so that qemu has to explicitly
enable the new NMI behaviour?  Or have I missed something that will
make that case work already.

-- 
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: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Axtens <dja@axtens.net>
Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>,
	paulus@ozlabs.org, linuxppc-dev@ozlabs.org,
	kvm-ppc@vger.kernel.org, mahesh@linux.vnet.ibm.com,
	agraf@suse.de, michaele@au1.ibm.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Exit guest upon fatal machine check exception
Date: Thu, 12 Nov 2015 03:38:16 +0000	[thread overview]
Message-ID: <20151112033816.GJ5852@voom.redhat.com> (raw)
In-Reply-To: <876118ymy4.fsf@gamma.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

On Thu, Nov 12, 2015 at 01:24:19PM +1100, Daniel Axtens wrote:
> Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes:
> 
> > This patch modifies KVM to cause a guest exit with
> > KVM_EXIT_NMI instead of immediately delivering a 0x200
> > interrupt to guest upon machine check exception in
> > guest address. Exiting the guest enables QEMU to build
> > error log and deliver machine check exception to guest
> > OS (either via guest OS registered machine check
> > handler or via 0x200 guest OS interrupt vector).
> >
> > This approach simplifies the delivering of machine
> > check exception to guest OS compared to the earlier approach
> > of KVM directly invoking 0x200 guest interrupt vector.
> > In the earlier approach QEMU patched the 0x200 interrupt
> > vector during boot. The patched code at 0x200 issued a
> > private hcall to pass the control to QEMU to build the
> > error log.
> >
> > This design/approach is based on the feedback for the
> > QEMU patches to handle machine check exception. Details
> > of earlier approach of handling machine check exception
> > in QEMU and related discussions can be found at:
> >
> > https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00813.html
> 
> I've poked at the MCE code, but not the KVM MCE code, so I may be
> mistaken here, but I'm not clear on how this handles errors that the
> guest can recover without terminating.
> 
> For example, a Linux guest can handle a UE in guest userspace by killing
> the guest process. A hypthetical non-linux guest with a microkernel
> could even survive UEs in drivers.
> 
> It sounds from your patch like you're changing this behaviour. Is this
> right?

So, IIUC.  Once the qemu pieces are in place as well it shouldn't
change this behaviour: KVM will exit to qemu, qemu will log the error
information (new), then reinject the MC to the guest which can still
handle it as you describe above.

But, there could be a problem if you have a new kernel with an old
qemu, in that case qemu might not understand the new exit type and
treat it as a fatal error, even though the guest could actually cope
with it.

Aravinda, do we need to change this so that qemu has to explicitly
enable the new NMI behaviour?  Or have I missed something that will
make that case work already.

-- 
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: 819 bytes --]

  reply	other threads:[~2015-11-12  3:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 16:58 [PATCH] KVM: PPC: Exit guest upon fatal machine check exception Aravinda Prasad
2015-11-11 16:59 ` Aravinda Prasad
2015-11-12  2:24 ` Daniel Axtens
2015-11-12  2:24   ` Daniel Axtens
2015-11-12  3:38   ` David Gibson [this message]
2015-11-12  3:38     ` David Gibson
2015-11-12  4:32     ` Aravinda Prasad
2015-11-12  4:44       ` Aravinda Prasad
2015-11-12  4:43       ` David Gibson
2015-11-12  4:43         ` David Gibson
2015-11-12 17:52         ` Aravinda Prasad
2015-11-12 17:52           ` Aravinda Prasad
2015-11-13  1:50           ` David Gibson
2015-11-13  1:50             ` David Gibson
2015-11-13  6:26             ` Aravinda Prasad
2015-11-13  6:38               ` Aravinda Prasad
2015-11-13  7:38               ` Thomas Huth
2015-11-13  7:38                 ` Thomas Huth
2015-11-13 11:25                 ` Aravinda Prasad
2015-11-13 11:37                   ` Aravinda Prasad
2015-11-12  4:58     ` Daniel Axtens
2015-11-12  4:58       ` Daniel Axtens
2015-11-12 17:22       ` Aravinda Prasad
2015-11-12 17:34         ` Aravinda Prasad
2015-11-12 21:37         ` Daniel Axtens
2015-11-12 21:37           ` Daniel Axtens
2015-11-13  4:58           ` Aravinda Prasad
2015-11-13  4:59             ` Aravinda Prasad
2015-11-12  3:34 ` David Gibson
2015-11-12  3:34   ` David Gibson
2015-11-12  5:18   ` Aravinda Prasad
2015-11-12  5:30     ` Aravinda Prasad

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=20151112033816.GJ5852@voom.redhat.com \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=dja@axtens.net \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=michaele@au1.ibm.com \
    --cc=paulus@ozlabs.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.