Message ID | 155323645659.18748.12592305605497011547.stgit@aravinda (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests | expand |
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? > + return; > + } > + > + if (ret < 0) { > + rtas_st(rets, 0, RTAS_OUT_HW_ERROR); > + return; > + } > + > spapr->mc_reset = 0; > spapr->guest_machine_check_addr = rtas_ld(args, 1); > rtas_st(rets, 0, RTAS_OUT_SUCCESS); > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c > index a593448..161b45e 100644 > --- a/target/ppc/kvm.c > +++ b/target/ppc/kvm.c > @@ -93,6 +93,7 @@ static int cap_ppc_safe_indirect_branch; > static int cap_ppc_count_cache_flush_assist; > static int cap_ppc_nested_kvm_hv; > static int cap_large_decr; > +static int cap_ppc_fwnmi; > > static uint32_t debug_inst_opcode; > > @@ -155,6 +156,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) > kvmppc_get_cpu_characteristics(s); > cap_ppc_nested_kvm_hv = kvm_vm_check_extension(s, KVM_CAP_PPC_NESTED_HV); > cap_large_decr = kvmppc_get_dec_bits(); > + cap_ppc_fwnmi = kvm_check_extension(s, KVM_CAP_PPC_FWNMI); > /* > * Note: setting it to false because there is not such capability > * in KVM at this moment. > @@ -2091,6 +2093,18 @@ void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) > } > } > > +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) > +{ > + CPUState *cs = CPU(cpu); > + > + if (!cap_ppc_fwnmi) { > + return 1; > + } > + > + return kvm_vcpu_enable_cap(cs, KVM_CAP_PPC_FWNMI, 0); > +} > + > + > int kvmppc_smt_threads(void) > { > return cap_ppc_smt ? cap_ppc_smt : 1; > diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h > index df5e85f..cf7b24f 100644 > --- a/target/ppc/kvm_ppc.h > +++ b/target/ppc/kvm_ppc.h > @@ -27,6 +27,7 @@ void kvmppc_enable_h_page_init(void); > void kvmppc_set_papr(PowerPCCPU *cpu); > int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr); > void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy); > +int kvmppc_fwnmi_enable(PowerPCCPU *cpu); > int kvmppc_smt_threads(void); > void kvmppc_hint_smt_possible(Error **errp); > int kvmppc_set_smt_threads(int smt); > @@ -158,6 +159,11 @@ static inline void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) > { > } > > +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) > +{ > + return 1; > +} > + > static inline int kvmppc_smt_threads(void) > { > return 1; >
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? Regards, Aravinda > >> + return; >> + } >> + >> + if (ret < 0) { >> + rtas_st(rets, 0, RTAS_OUT_HW_ERROR); >> + return; >> + } >> + >> spapr->mc_reset = 0; >> spapr->guest_machine_check_addr = rtas_ld(args, 1); >> rtas_st(rets, 0, RTAS_OUT_SUCCESS); >> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c >> index a593448..161b45e 100644 >> --- a/target/ppc/kvm.c >> +++ b/target/ppc/kvm.c >> @@ -93,6 +93,7 @@ static int cap_ppc_safe_indirect_branch; >> static int cap_ppc_count_cache_flush_assist; >> static int cap_ppc_nested_kvm_hv; >> static int cap_large_decr; >> +static int cap_ppc_fwnmi; >> >> static uint32_t debug_inst_opcode; >> >> @@ -155,6 +156,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) >> kvmppc_get_cpu_characteristics(s); >> cap_ppc_nested_kvm_hv = kvm_vm_check_extension(s, KVM_CAP_PPC_NESTED_HV); >> cap_large_decr = kvmppc_get_dec_bits(); >> + cap_ppc_fwnmi = kvm_check_extension(s, KVM_CAP_PPC_FWNMI); >> /* >> * Note: setting it to false because there is not such capability >> * in KVM at this moment. >> @@ -2091,6 +2093,18 @@ void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) >> } >> } >> >> +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) >> +{ >> + CPUState *cs = CPU(cpu); >> + >> + if (!cap_ppc_fwnmi) { >> + return 1; >> + } >> + >> + return kvm_vcpu_enable_cap(cs, KVM_CAP_PPC_FWNMI, 0); >> +} >> + >> + >> int kvmppc_smt_threads(void) >> { >> return cap_ppc_smt ? cap_ppc_smt : 1; >> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h >> index df5e85f..cf7b24f 100644 >> --- a/target/ppc/kvm_ppc.h >> +++ b/target/ppc/kvm_ppc.h >> @@ -27,6 +27,7 @@ void kvmppc_enable_h_page_init(void); >> void kvmppc_set_papr(PowerPCCPU *cpu); >> int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr); >> void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy); >> +int kvmppc_fwnmi_enable(PowerPCCPU *cpu); >> int kvmppc_smt_threads(void); >> void kvmppc_hint_smt_possible(Error **errp); >> int kvmppc_set_smt_threads(int smt); >> @@ -158,6 +159,11 @@ static inline void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) >> { >> } >> >> +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) >> +{ >> + return 1; >> +} >> + >> static inline int kvmppc_smt_threads(void) >> { >> return 1; >> >
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.
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. Ok I will update the patch. >
Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes: (...) > diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h > index df5e85f..cf7b24f 100644 > --- a/target/ppc/kvm_ppc.h > +++ b/target/ppc/kvm_ppc.h > @@ -27,6 +27,7 @@ void kvmppc_enable_h_page_init(void); > void kvmppc_set_papr(PowerPCCPU *cpu); > int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr); > void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy); > +int kvmppc_fwnmi_enable(PowerPCCPU *cpu); Building for all architectures results in: In file included from qemu/hw/ppc/ppc.c:36: qemu/target/ppc/kvm_ppc.h:162:5: error: no previous prototype for ‘kvmppc_fwnmi_enable’ [-Werror=missing-prototypes] int kvmppc_fwnmi_enable(PowerPCCPU *cpu) ^~~~~~~~~~~~~~~~~~~ > int kvmppc_smt_threads(void); > void kvmppc_hint_smt_possible(Error **errp); > int kvmppc_set_smt_threads(int smt); > @@ -158,6 +159,11 @@ static inline void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) > { > } > > +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) > +{ > + return 1; > +} > + > static inline int kvmppc_smt_threads(void) > { > return 1;
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? >
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.
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); + return; + } + + if (ret < 0) { + rtas_st(rets, 0, RTAS_OUT_HW_ERROR); + return; + } + spapr->mc_reset = 0; spapr->guest_machine_check_addr = rtas_ld(args, 1); rtas_st(rets, 0, RTAS_OUT_SUCCESS); diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c index a593448..161b45e 100644 --- a/target/ppc/kvm.c +++ b/target/ppc/kvm.c @@ -93,6 +93,7 @@ static int cap_ppc_safe_indirect_branch; static int cap_ppc_count_cache_flush_assist; static int cap_ppc_nested_kvm_hv; static int cap_large_decr; +static int cap_ppc_fwnmi; static uint32_t debug_inst_opcode; @@ -155,6 +156,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) kvmppc_get_cpu_characteristics(s); cap_ppc_nested_kvm_hv = kvm_vm_check_extension(s, KVM_CAP_PPC_NESTED_HV); cap_large_decr = kvmppc_get_dec_bits(); + cap_ppc_fwnmi = kvm_check_extension(s, KVM_CAP_PPC_FWNMI); /* * Note: setting it to false because there is not such capability * in KVM at this moment. @@ -2091,6 +2093,18 @@ void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) } } +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) +{ + CPUState *cs = CPU(cpu); + + if (!cap_ppc_fwnmi) { + return 1; + } + + return kvm_vcpu_enable_cap(cs, KVM_CAP_PPC_FWNMI, 0); +} + + int kvmppc_smt_threads(void) { return cap_ppc_smt ? cap_ppc_smt : 1; diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h index df5e85f..cf7b24f 100644 --- a/target/ppc/kvm_ppc.h +++ b/target/ppc/kvm_ppc.h @@ -27,6 +27,7 @@ void kvmppc_enable_h_page_init(void); void kvmppc_set_papr(PowerPCCPU *cpu); int kvmppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr); void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy); +int kvmppc_fwnmi_enable(PowerPCCPU *cpu); int kvmppc_smt_threads(void); void kvmppc_hint_smt_possible(Error **errp); int kvmppc_set_smt_threads(int smt); @@ -158,6 +159,11 @@ static inline void kvmppc_set_mpic_proxy(PowerPCCPU *cpu, int mpic_proxy) { } +int kvmppc_fwnmi_enable(PowerPCCPU *cpu) +{ + return 1; +} + static inline int kvmppc_smt_threads(void) { return 1;
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(+)