From: Thomas Huth <thuth@redhat.com>
To: Aravinda Prasad <aravinda@linux.vnet.ibm.com>,
paulus@ozlabs.org, linuxppc-dev@ozlabs.org,
kvm-ppc@vger.kernel.org
Cc: mahesh@linux.vnet.ibm.com, michaele@au1.ibm.com, agraf@suse.de,
kvm@vger.kernel.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH v2] KVM: PPC: Exit guest upon fatal machine check exception
Date: Wed, 16 Dec 2015 10:40:28 +0100 [thread overview]
Message-ID: <5671318C.5040001@redhat.com> (raw)
In-Reply-To: <20151216055612.10203.28496.stgit@aravindap>
On 16/12/15 06:56, Aravinda Prasad wrote:
> 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
>
> This patch also introduces a new KVM capability to
> control how KVM behaves on machine check exception.
> Without this capability, KVM redirects machine check
> exceptions to guest's 0x200 vector if the address in
> error belongs to guest. With this capability KVM
> causes a guest exit with NMI exit reason.
>
> This is required to avoid problems if a new kernel/KVM
> is used with an old QEMU for guests that don't issue
> "ibm,nmi-register". As old QEMU does not understand the
> NMI exit type, it treats it as a fatal error. However,
> the guest could have handled the machine check error
> if the exception was delivered to guest's 0x200 interrupt
> vector instead of NMI exit in case of old QEMU.
>
> Change Log v2:
> - Added KVM capability
>
> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kvm/book3s_hv.c | 12 +++-------
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 37 +++++++++++++++----------------
> arch/powerpc/kvm/powerpc.c | 7 ++++++
> include/uapi/linux/kvm.h | 1 +
> 6 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 827a38d..8a652ba 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -243,6 +243,7 @@ struct kvm_arch {
> int hpt_cma_alloc;
> struct dentry *debugfs_dir;
> struct dentry *htab_dentry;
> + u8 fwnmi_enabled;
Here you declare the variable as 8-bits ...
> #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
> struct mutex hpt_mutex;
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index 221d584..6a4e81a 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -506,6 +506,7 @@ int main(void)
> DEFINE(KVM_ENABLED_HCALLS, offsetof(struct kvm, arch.enabled_hcalls));
> DEFINE(KVM_LPCR, offsetof(struct kvm, arch.lpcr));
> DEFINE(KVM_VRMA_SLB_V, offsetof(struct kvm, arch.vrma_slb_v));
> + DEFINE(KVM_FWNMI, offsetof(struct kvm, arch.fwnmi_enabled));
... then define an asm-offset for it ...
> DEFINE(VCPU_DSISR, offsetof(struct kvm_vcpu, arch.shregs.dsisr));
> DEFINE(VCPU_DAR, offsetof(struct kvm_vcpu, arch.shregs.dar));
> DEFINE(VCPU_VPA, offsetof(struct kvm_vcpu, arch.vpa.pinned_addr));
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index b98889e..f43c124 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
[...]
> @@ -2381,24 +2377,27 @@ machine_check_realmode:
> ld r9, HSTATE_KVM_VCPU(r13)
> li r12, BOOK3S_INTERRUPT_MACHINE_CHECK
> /*
> - * Deliver unhandled/fatal (e.g. UE) MCE errors to guest through
> - * machine check interrupt (set HSRR0 to 0x200). And for handled
> - * errors (no-fatal), just go back to guest execution with current
> - * HSRR0 instead of exiting guest. This new approach will inject
> - * machine check to guest for fatal error causing guest to crash.
> - *
> - * The old code used to return to host for unhandled errors which
> - * was causing guest to hang with soft lockups inside guest and
> - * makes it difficult to recover guest instance.
> + * Deliver unhandled/fatal (e.g. UE) MCE errors to guest
> + * by exiting the guest with KVM_EXIT_NMI exit reason (exit
> + * reason set later based on trap). For handled errors
> + * (no-fatal), go back to guest execution with current HSRR0
> + * instead of exiting the guest. This approach will cause
> + * the guest to exit in case of fatal machine check error.
> */
> - ld r10, VCPU_PC(r9)
> - ld r11, VCPU_MSR(r9)
> - bne 2f /* Continue guest execution. */
> - /* If not, deliver a machine check. SRR0/1 are already set */
> - li r10, BOOK3S_INTERRUPT_MACHINE_CHECK
> + bne 2f /* Continue guest execution? */
> + /* If not, check if guest is capable of handling NMI exit */
> + ld r3, VCPU_KVM(r9)
> + ld r3, KVM_FWNMI(r3)
> + cmpdi r3, 1 /* FWNMI capable? */
... and here you're accessing the 8-bit variable with "ld" and "cmpdi"!
Is this really working as expected? Or did I miss something? Did you
check your code on both, little and big endian hosts?
Thomas
next prev parent reply other threads:[~2015-12-16 9:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 5:56 [PATCH v2] KVM: PPC: Exit guest upon fatal machine check exception Aravinda Prasad
2015-12-16 6:13 ` Daniel Axtens
2015-12-16 9:40 ` Thomas Huth [this message]
2015-12-16 11:16 ` Aravinda Prasad
2015-12-17 2:32 ` David Gibson
2015-12-17 4:19 ` 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=5671318C.5040001@redhat.com \
--to=thuth@redhat.com \
--cc=agraf@suse.de \
--cc=aravinda@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--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 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).