From: Greg Kurz <groug@kaod.org> To: Alexey Kardashevskiy <aik@linux.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au>, Aravinda Prasad <aravinda@linux.vnet.ibm.com>, paulus@ozlabs.org, qemu-ppc@nongnu.org, aik@au1.ibm.com, qemu-devel@nongnu.org, mahesh@linux.vnet.ibm.com Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 3/6] target/ppc: Handle NMI guest exit Date: Fri, 5 Apr 2019 10:18:26 +0200 [thread overview] Message-ID: <20190405101826.0255f9c5@bahia.lan> (raw) In-Reply-To: <cd08ddbc-d289-04a5-c9ae-d7618fc22308@linux.ibm.com> On Fri, 5 Apr 2019 16:04:27 +1100 Alexey Kardashevskiy <aik@linux.ibm.com> wrote: > On 05/04/2019 10:17, David Gibson wrote: > > On Thu, Apr 04, 2019 at 02:40:45PM +0530, Aravinda Prasad wrote: > >> > >> > >> On Monday 25 March 2019 11:52 AM, David Gibson wrote: > >>> On Fri, Mar 22, 2019 at 12:03:58PM +0530, Aravinda Prasad wrote: > >>>> Memory error such as bit flips that cannot be corrected > >>>> by hardware are passed on to the kernel for handling. > >>>> If the memory address in error belongs to guest then > >>>> the guest kernel is responsible for taking suitable action. > >>>> Patch [1] enhances KVM to exit guest with exit reason > >>>> set to KVM_EXIT_NMI in such cases. This patch handles > >>>> KVM_EXIT_NMI exit. > >>>> > >>>> [1] https://www.spinics.net/lists/kvm-ppc/msg12637.html > >>>> (e20bbd3d and related commits) > >>>> > >>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com> > >>>> --- > >>>> hw/ppc/spapr_events.c | 22 ++++++++++++++++++++++ > >>>> include/hw/ppc/spapr.h | 1 + > >>>> target/ppc/kvm.c | 16 ++++++++++++++++ > >>>> target/ppc/kvm_ppc.h | 2 ++ > >>>> 4 files changed, 41 insertions(+) > >>>> > >> > >> [...] > >> > >>>> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c > >>>> index 2427c8e..a593448 100644 > >>>> --- a/target/ppc/kvm.c > >>>> +++ b/target/ppc/kvm.c > >>>> @@ -1738,6 +1738,11 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run) > >>>> ret = 0; > >>>> break; > >>>> > >>>> + case KVM_EXIT_NMI: > >>>> + DPRINTF("handle NMI exception\n"); > >>> > >>> tracepoints are generally preferred to new DPRINTFs. > >> > >> I see DPRINTFs used in all other exit reasons in this function. Do you > >> want me to change this particular exit case to tracepoints? I think it > >> is better to keep this DPRINTF as of now and change all the DPRINTFs to > >> tracepoints in a separate patch set. > > > > Ah, good point. > > imho not. The kvm.c already knows about traces (there are two) and even > if every other trace in kvm_arch_handle_exit() is DPRINTF (enabled all > at once), having at least one which can be enabled without QEMU > recompile and separately from the others is a small but nice bonus > before someone gets rid of DPRINTF. > Done. https://patchwork.ozlabs.org/project/qemu-devel/list/?series=101141 > > > Tracepoints are generally preferred, but since > > DPRINTFs are in use here, stick with that (at some point it would be > > good to change the whole file, but that's out of scope here). > >
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kurz <groug@kaod.org> To: Alexey Kardashevskiy <aik@linux.ibm.com> Cc: aik@au1.ibm.com, qemu-devel@nongnu.org, paulus@ozlabs.org, qemu-ppc@nongnu.org, Aravinda Prasad <aravinda@linux.vnet.ibm.com>, David Gibson <david@gibson.dropbear.id.au> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 3/6] target/ppc: Handle NMI guest exit Date: Fri, 5 Apr 2019 10:18:26 +0200 [thread overview] Message-ID: <20190405101826.0255f9c5@bahia.lan> (raw) Message-ID: <20190405081826.vqCxwqcv1Zll9Ou1ZoCJlTtPYJdSbLzDQJ1qNGDUUKY@z> (raw) In-Reply-To: <cd08ddbc-d289-04a5-c9ae-d7618fc22308@linux.ibm.com> On Fri, 5 Apr 2019 16:04:27 +1100 Alexey Kardashevskiy <aik@linux.ibm.com> wrote: > On 05/04/2019 10:17, David Gibson wrote: > > On Thu, Apr 04, 2019 at 02:40:45PM +0530, Aravinda Prasad wrote: > >> > >> > >> On Monday 25 March 2019 11:52 AM, David Gibson wrote: > >>> On Fri, Mar 22, 2019 at 12:03:58PM +0530, Aravinda Prasad wrote: > >>>> Memory error such as bit flips that cannot be corrected > >>>> by hardware are passed on to the kernel for handling. > >>>> If the memory address in error belongs to guest then > >>>> the guest kernel is responsible for taking suitable action. > >>>> Patch [1] enhances KVM to exit guest with exit reason > >>>> set to KVM_EXIT_NMI in such cases. This patch handles > >>>> KVM_EXIT_NMI exit. > >>>> > >>>> [1] https://www.spinics.net/lists/kvm-ppc/msg12637.html > >>>> (e20bbd3d and related commits) > >>>> > >>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com> > >>>> --- > >>>> hw/ppc/spapr_events.c | 22 ++++++++++++++++++++++ > >>>> include/hw/ppc/spapr.h | 1 + > >>>> target/ppc/kvm.c | 16 ++++++++++++++++ > >>>> target/ppc/kvm_ppc.h | 2 ++ > >>>> 4 files changed, 41 insertions(+) > >>>> > >> > >> [...] > >> > >>>> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c > >>>> index 2427c8e..a593448 100644 > >>>> --- a/target/ppc/kvm.c > >>>> +++ b/target/ppc/kvm.c > >>>> @@ -1738,6 +1738,11 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run) > >>>> ret = 0; > >>>> break; > >>>> > >>>> + case KVM_EXIT_NMI: > >>>> + DPRINTF("handle NMI exception\n"); > >>> > >>> tracepoints are generally preferred to new DPRINTFs. > >> > >> I see DPRINTFs used in all other exit reasons in this function. Do you > >> want me to change this particular exit case to tracepoints? I think it > >> is better to keep this DPRINTF as of now and change all the DPRINTFs to > >> tracepoints in a separate patch set. > > > > Ah, good point. > > imho not. The kvm.c already knows about traces (there are two) and even > if every other trace in kvm_arch_handle_exit() is DPRINTF (enabled all > at once), having at least one which can be enabled without QEMU > recompile and separately from the others is a small but nice bonus > before someone gets rid of DPRINTF. > Done. https://patchwork.ozlabs.org/project/qemu-devel/list/?series=101141 > > > Tracepoints are generally preferred, but since > > DPRINTFs are in use here, stick with that (at some point it would be > > good to change the whole file, but that's out of scope here). > >
next prev parent reply other threads:[~2019-04-05 8:18 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <155323635511.18748.18133954505098138975.stgit@aravinda> [not found] ` <155323643836.18748.13006461397179281455.stgit@aravinda> [not found] ` <20190325062256.GO29295@umbus> 2019-04-04 9:10 ` [Qemu-devel] [PATCH v7 3/6] target/ppc: Handle NMI guest exit Aravinda Prasad 2019-04-04 9:35 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz 2019-04-04 23:17 ` [Qemu-devel] " David Gibson 2019-04-04 23:17 ` David Gibson 2019-04-05 5:04 ` Alexey Kardashevskiy 2019-04-05 5:04 ` Alexey Kardashevskiy 2019-04-05 8:18 ` Greg Kurz [this message] 2019-04-05 8:18 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz [not found] ` <155323645659.18748.12592305605497011547.stgit@aravinda> 2019-04-04 20:44 ` [Qemu-devel] [PATCH v7 5/6] ppc: spapr: Enable FWNMI capability Fabiano Rosas [not found] ` <20190325063205.GQ29295@umbus> [not found] ` <9da8a51d-106c-410e-fa88-d37dceb0c9e1@linux.vnet.ibm.com> [not found] ` <20190325233319.GD9393@umbus.fritz.box> 2019-04-15 10:12 ` [Qemu-devel] [Qemu-ppc] " Aravinda Prasad 2019-04-15 10:12 ` Aravinda Prasad 2019-04-17 2:09 ` David Gibson 2019-04-17 2:09 ` 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=20190405101826.0255f9c5@bahia.lan \ --to=groug@kaod.org \ --cc=aik@au1.ibm.com \ --cc=aik@linux.ibm.com \ --cc=aravinda@linux.vnet.ibm.com \ --cc=david@gibson.dropbear.id.au \ --cc=mahesh@linux.vnet.ibm.com \ --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: linkBe 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).