From: David Gibson <david@gibson.dropbear.id.au>
To: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Cc: 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 5/6] ppc: spapr: Enable FWNMI capability
Date: Wed, 17 Apr 2019 12:09:28 +1000 [thread overview]
Message-ID: <20190417020928.GJ32705@umbus.fritz.box> (raw)
In-Reply-To: <93ee6877-b487-1733-a368-3887f105f5a3@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4856 bytes --]
On Mon, Apr 15, 2019 at 03:42:46PM +0530, Aravinda Prasad wrote:
>
>
> On Tuesday 26 March 2019 05:03 AM, David Gibson wrote:
> > On Mon, Mar 25, 2019 at 02:27:45PM +0530, Aravinda Prasad wrote:
> >>
> >>
> >> On Monday 25 March 2019 12:02 PM, David Gibson wrote:
> >>> On Fri, Mar 22, 2019 at 12:04:16PM +0530, Aravinda Prasad wrote:
> >>>> Enable the KVM capability KVM_CAP_PPC_FWNMI so that
> >>>> the KVM causes guest exit with NMI as exit reason
> >>>> when it encounters a machine check exception on the
> >>>> address belonging to a guest. Without this capability
> >>>> enabled, KVM redirects machine check exceptions to
> >>>> guest's 0x200 vector.
> >>>>
> >>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> >>>> ---
> >>>> hw/ppc/spapr_rtas.c | 15 +++++++++++++++
> >>>> target/ppc/kvm.c | 14 ++++++++++++++
> >>>> target/ppc/kvm_ppc.h | 6 ++++++
> >>>> 3 files changed, 35 insertions(+)
> >>>>
> >>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> >>>> index fb594a4..939f428 100644
> >>>> --- a/hw/ppc/spapr_rtas.c
> >>>> +++ b/hw/ppc/spapr_rtas.c
> >>>> @@ -49,6 +49,7 @@
> >>>> #include "hw/ppc/fdt.h"
> >>>> #include "target/ppc/mmu-hash64.h"
> >>>> #include "target/ppc/mmu-book3s-v3.h"
> >>>> +#include "kvm_ppc.h"
> >>>>
> >>>> static void rtas_display_character(PowerPCCPU *cpu, SpaprMachineState *spapr,
> >>>> uint32_t token, uint32_t nargs,
> >>>> @@ -354,6 +355,20 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
> >>>> target_ulong args,
> >>>> uint32_t nret, target_ulong rets)
> >>>> {
> >>>> + int ret;
> >>>> +
> >>>> + ret = kvmppc_fwnmi_enable(cpu);
> >>>> +
> >>>> + if (ret == 1) {
> >>>> + rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
> >>>
> >>> Urgh, we're here making a guest visible different to the environment
> >>> depending on a host (KVM) capability. What happens if you start a
> >>> guest and it registers fwnmi support, then migrate it to a host that
> >>> lacks the necessary KVM support?
> >>
> >> I just checked how such scenarios are handled for other KVM
> >> capabilities. Should I need to add an Spapr cap for this?
> >
> > Yes, I think that's what we'll need to do.
>
> I was looking into SPAPR Cap, and I am not sure that the following code
> will help in handling the migration. I need some help here.
>
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index edc5ed0..ef96192 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -473,6 +473,15 @@ static void cap_ccf_assist_apply(SpaprMachineState
> *spapr, uint8_t val,
> }
> }
>
> +static void cap_machine_check_apply(SpaprMachineState *spapr, uint8_t val,
> + Error **errp)
> +{
> + if (kvm_enabled()) {
> + if (kvmppc_fwnmi_enable(cpu)) {
> + error_setg(errp, "Unable to enable fwnmi capability");
> + }
> +}
> +
> SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> [SPAPR_CAP_HTM] = {
> .name = "htm",
> @@ -571,6 +580,15 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> .type = "bool",
> .apply = cap_ccf_assist_apply,
> },
> + [SPAPR_CAP_MACHINE_CHECK] = {
> + .name = "machine-check",
> + .description = "Handle machine check exceptions",
> + .index = SPAPR_CAP_MACHINE_CHECK,
> + .get = spapr_cap_get_bool,
> + .set = spapr_cap_set_bool,
> + .type = "bool",
> + .apply = cap_machine_check_apply,
> + },
> };
>
> static SpaprCapabilities default_caps_with_cpu(SpaprMachineState *spapr,
> @@ -706,6 +724,7 @@ SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
> SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
> SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
> SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
> +SPAPR_CAP_MIG_STATE(mce, SPAPR_CAP_MACHINE_CHECK);
>
> void spapr_caps_init(SpaprMachineState *spapr)
> {
>
>
> Or is it that just adding SPAPR_CAP_MIG_STATE(mce,
> SPAPR_CAP_MACHINE_CHECK); is enough as it is checking or cap values?
No, the change you have above looks mostly good. You'll also need to
set default values for the cap in spapr_machine_class_init(), and
probably compat values in some of the earlier machine type variants.
I also don't like the cap name: there's at least some kind of handling
of machine checks before this, this is more specifically about the
fwnmi scheme, AIUI.
--
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 --]
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Cc: paulus@ozlabs.org, aik@au1.ibm.com, qemu-ppc@nongnu.org,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 5/6] ppc: spapr: Enable FWNMI capability
Date: Wed, 17 Apr 2019 12:09:28 +1000 [thread overview]
Message-ID: <20190417020928.GJ32705@umbus.fritz.box> (raw)
Message-ID: <20190417020928.cV11FKXBQ1-CCkoZYDKuveYWjdOrD7JcNIV4s0AcVfk@z> (raw)
In-Reply-To: <93ee6877-b487-1733-a368-3887f105f5a3@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4856 bytes --]
On Mon, Apr 15, 2019 at 03:42:46PM +0530, Aravinda Prasad wrote:
>
>
> On Tuesday 26 March 2019 05:03 AM, David Gibson wrote:
> > On Mon, Mar 25, 2019 at 02:27:45PM +0530, Aravinda Prasad wrote:
> >>
> >>
> >> On Monday 25 March 2019 12:02 PM, David Gibson wrote:
> >>> On Fri, Mar 22, 2019 at 12:04:16PM +0530, Aravinda Prasad wrote:
> >>>> Enable the KVM capability KVM_CAP_PPC_FWNMI so that
> >>>> the KVM causes guest exit with NMI as exit reason
> >>>> when it encounters a machine check exception on the
> >>>> address belonging to a guest. Without this capability
> >>>> enabled, KVM redirects machine check exceptions to
> >>>> guest's 0x200 vector.
> >>>>
> >>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> >>>> ---
> >>>> hw/ppc/spapr_rtas.c | 15 +++++++++++++++
> >>>> target/ppc/kvm.c | 14 ++++++++++++++
> >>>> target/ppc/kvm_ppc.h | 6 ++++++
> >>>> 3 files changed, 35 insertions(+)
> >>>>
> >>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> >>>> index fb594a4..939f428 100644
> >>>> --- a/hw/ppc/spapr_rtas.c
> >>>> +++ b/hw/ppc/spapr_rtas.c
> >>>> @@ -49,6 +49,7 @@
> >>>> #include "hw/ppc/fdt.h"
> >>>> #include "target/ppc/mmu-hash64.h"
> >>>> #include "target/ppc/mmu-book3s-v3.h"
> >>>> +#include "kvm_ppc.h"
> >>>>
> >>>> static void rtas_display_character(PowerPCCPU *cpu, SpaprMachineState *spapr,
> >>>> uint32_t token, uint32_t nargs,
> >>>> @@ -354,6 +355,20 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
> >>>> target_ulong args,
> >>>> uint32_t nret, target_ulong rets)
> >>>> {
> >>>> + int ret;
> >>>> +
> >>>> + ret = kvmppc_fwnmi_enable(cpu);
> >>>> +
> >>>> + if (ret == 1) {
> >>>> + rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
> >>>
> >>> Urgh, we're here making a guest visible different to the environment
> >>> depending on a host (KVM) capability. What happens if you start a
> >>> guest and it registers fwnmi support, then migrate it to a host that
> >>> lacks the necessary KVM support?
> >>
> >> I just checked how such scenarios are handled for other KVM
> >> capabilities. Should I need to add an Spapr cap for this?
> >
> > Yes, I think that's what we'll need to do.
>
> I was looking into SPAPR Cap, and I am not sure that the following code
> will help in handling the migration. I need some help here.
>
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index edc5ed0..ef96192 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -473,6 +473,15 @@ static void cap_ccf_assist_apply(SpaprMachineState
> *spapr, uint8_t val,
> }
> }
>
> +static void cap_machine_check_apply(SpaprMachineState *spapr, uint8_t val,
> + Error **errp)
> +{
> + if (kvm_enabled()) {
> + if (kvmppc_fwnmi_enable(cpu)) {
> + error_setg(errp, "Unable to enable fwnmi capability");
> + }
> +}
> +
> SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> [SPAPR_CAP_HTM] = {
> .name = "htm",
> @@ -571,6 +580,15 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> .type = "bool",
> .apply = cap_ccf_assist_apply,
> },
> + [SPAPR_CAP_MACHINE_CHECK] = {
> + .name = "machine-check",
> + .description = "Handle machine check exceptions",
> + .index = SPAPR_CAP_MACHINE_CHECK,
> + .get = spapr_cap_get_bool,
> + .set = spapr_cap_set_bool,
> + .type = "bool",
> + .apply = cap_machine_check_apply,
> + },
> };
>
> static SpaprCapabilities default_caps_with_cpu(SpaprMachineState *spapr,
> @@ -706,6 +724,7 @@ SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
> SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
> SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
> SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
> +SPAPR_CAP_MIG_STATE(mce, SPAPR_CAP_MACHINE_CHECK);
>
> void spapr_caps_init(SpaprMachineState *spapr)
> {
>
>
> Or is it that just adding SPAPR_CAP_MIG_STATE(mce,
> SPAPR_CAP_MACHINE_CHECK); is enough as it is checking or cap values?
No, the change you have above looks mostly good. You'll also need to
set default values for the cap in spapr_machine_class_init(), and
probably compat values in some of the earlier machine type variants.
I also don't like the cap name: there's at least some kind of handling
of machine checks before this, this is more specifically about the
fwnmi scheme, AIUI.
--
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-04-17 3:05 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 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-04-05 8:18 ` 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 [this message]
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=20190417020928.GJ32705@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@au1.ibm.com \
--cc=aravinda@linux.vnet.ibm.com \
--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: 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).