[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v3 0/5] target-ppc/spapr: Add FWNMI support in QEM

From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH v3 0/5] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests
Date: Wed, 23 Aug 2017 10:43:37 +1000
User-agent: Mutt/1.8.3 (2017-05-23)

On Mon, Aug 21, 2017 at 02:40:17PM +0530, Aravinda Prasad wrote:
> On Thursday 17 August 2017 09:05 AM, Sam Bobroff wrote:
> > On Wed, Aug 16, 2017 at 02:41:59PM +0530, Aravinda Prasad wrote:
> >> This series of patches adds support for FWNMI in PowerKVM guests.
> >>
> >> Memory error such as bit flips that cannot be corrected
> >> by hardware is passed on to the kernel for handling
> >> by raising machine check exception (an NMI). Upon such
> >> machine check exception, if the address in error belongs
> >> to guest then KVM causes a guest exit with KVM_EXIT_NMI
> >> exit reason.
> >>
> >> This patch series adds functionality to pass on such
> >> machine check exception to the guest kernel by suitably
> >> handling KVM_EXIT_NMI exit and building the error log.
> >>
> >> The KVM changes are now part of the upstream kernel
> >> (commit e20bbd3d). This series contain QEMU changes.
> > 
> > [snip]
> > 
> > Hi,
> > 
> > I'm concerned that this implementation may introduce a problem with
> > kexec. If a VM registers an NMI handler, then kexecs to a new kernel
> > and an NMI is received before the new kernel has registered it's
> > handler, won't QEMU cause the guest to jump to the old, now invalid,
> > handler address? Is this worth worrying about?
> I think there is a small time window till the kexec kernel registers a
> new handler during which NMI can branch to the old invalid address.
> Two points of interest. First, I did not find any "ibm,nmi-unregister"
> call. Hence, once the VM registers for NMI it cannot unregister it.
> Second, if kexec is triggered due to VM crash, then the guest will not
> get the opportunity to unregister NMI even in case something similar to
> "ibm,nmi-unregister" is available.
> Not sure if this is worth handling as machine check NMIs are rare, and
> getting a machine check NMI during that small time window is very
> rare.

I tend to agree.  PAPR basically doesn't let us fix this, so crossing
our fingers and hoping not get an NMI in the window is about the best
we can do.

We could potentially define a way to unregister (e.g. passing 0,0 or
0x100,0x200 to nmi-register, maybe), but that can be an enhancement
for another day.

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_!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]