[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] target/ppc/kvm: Use KVM_CAP_PPC_AIL_MODE_3 to determine
From: |
David Gibson |
Subject: |
Re: [PATCH 2/2] target/ppc/kvm: Use KVM_CAP_PPC_AIL_MODE_3 to determine cap-ail-mode-3 support |
Date: |
Wed, 16 Feb 2022 15:58:34 +1100 |
>On Wed, Feb 16, 2022 at 11:46:58AM +1000, Nicholas Piggin wrote:
> Excerpts from Fabiano Rosas's message of February 15, 2022 10:21 pm:
> > Nicholas Piggin <npiggin@gmail.com> writes:
> >
> >> Excerpts from Fabiano Rosas's message of February 14, 2022 11:13 pm:
> >>> Nicholas Piggin <npiggin@gmail.com> writes:
> >>>
> >>>> Use KVM_CAP_PPC_AIL_MODE_3 to determine cap-ail-mode-3 support for KVM
> >>>> guests. Keep the fallback heuristic for KVM hosts that pre-date this
> >>>> CAP.
> >>>>
> >>>> This is only proposed the KVM CAP has not yet been allocated. I will
> >>>> ask to merge the new KVM cap when there are no objections on the QEMU
> >>>> side.
> >>>>
> >>>> not-yet-Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> >>>> ---
> >>>> hw/ppc/spapr_caps.c | 2 +-
> >>>> linux-headers/linux/kvm.h | 1 +
> >>>> target/ppc/kvm.c | 18 +++++++++++++++++-
> >>>> target/ppc/kvm_ppc.h | 4 ++--
> >>>> 4 files changed, 21 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> >>>> index 5fd4a53c33..5cc80776d0 100644
> >>>> --- a/hw/ppc/spapr_caps.c
> >>>> +++ b/hw/ppc/spapr_caps.c
> >>>> @@ -619,7 +619,7 @@ static void cap_ail_mode_3_apply(SpaprMachineState
> >>>> *spapr,
> >>>> ERRP_GUARD();
> >>>>
> >>>> if (kvm_enabled()) {
> >>>> - if (!kvmppc_supports_ail_3()) {
> >>>> + if (!kvmppc_has_cap_ail_3()) {
> >>>> error_setg(errp, "KVM implementation does not support
> >>>> cap-ail-mode-3");
> >>>> error_append_hint(errp, "Try appending -machine
> >>>> cap-ail-mode-3=off\n");
> >>>> return;
> >>>> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> >>>> index 02c5e7b7bb..d91f578200 100644
> >>>> --- a/linux-headers/linux/kvm.h
> >>>> +++ b/linux-headers/linux/kvm.h
> >>>> @@ -1130,6 +1130,7 @@ struct kvm_ppc_resize_hpt {
> >>>> #define KVM_CAP_BINARY_STATS_FD 203
> >>>> #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
> >>>> #define KVM_CAP_ARM_MTE 205
> >>>> +#define KVM_CAP_PPC_AIL_MODE_3 210
> >>>>
> >>>> #ifdef KVM_CAP_IRQ_ROUTING
> >>>>
> >>>> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> >>>> index 128bc530d4..d0d0bdaac4 100644
> >>>> --- a/target/ppc/kvm.c
> >>>> +++ b/target/ppc/kvm.c
> >>>> @@ -90,6 +90,7 @@ static int cap_ppc_nested_kvm_hv;
> >>>> static int cap_large_decr;
> >>>> static int cap_fwnmi;
> >>>> static int cap_rpt_invalidate;
> >>>> +static int cap_ail_mode_3;
> >>>>
> >>>> static uint32_t debug_inst_opcode;
> >>>>
> >>>> @@ -154,6 +155,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> >>>> }
> >>>>
> >>>> cap_rpt_invalidate = kvm_vm_check_extension(s,
> >>>> KVM_CAP_PPC_RPT_INVALIDATE);
> >>>> + cap_ail_mode_3 = kvm_vm_check_extension(s, KVM_CAP_PPC_AIL_MODE_3);
> >>>> kvm_ppc_register_host_cpu_type();
> >>>>
> >>>> return 0;
> >>>> @@ -2563,10 +2565,24 @@ int kvmppc_has_cap_rpt_invalidate(void)
> >>>> return cap_rpt_invalidate;
> >>>> }
> >>>>
> >>>> -int kvmppc_supports_ail_3(void)
> >>>> +int kvmppc_has_cap_ail_3(void)
> >>>> {
> >>>> PowerPCCPUClass *pcc = kvm_ppc_get_host_cpu_class();
> >>>>
> >>>> + if (cap_ail_mode_3) {
> >>>> + return 1;
> >>>> + }
> >>>> +
> >>>> + if (kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION,
> >>>> KVM_CAP_PPC_AIL_MODE_3) == 0) {
> >>>> + return 0;
> >>>> + }
> >>>
> >>> This is not needed here it seems.
> >>
> >> This is to test whether the capability is recognised by the HV.
> >> kvm_vm_check_extension() treats ioctl error as 0 capability but we want
> >> to do this extra heuristic.
> >
> > Do you intend to make the KVM capability return < 0 in case AIL_3 is not
> > supported?
>
> No it should return 0 in that case.
>
> > AFAICS the unknown capability won't result in an ioctl error
> > as kvm_vm_ioctl_check_extension always returns >= 0.
>
> Oh. There is no way to tell that a host does not recognise a cap? :(
Not short of giving it all non-zero values when you create the new cap.
> Great for the purity test, unknown cap == unsupported. For a practical
> point of view to catch such bugs and oversights there should have been
> some way to handle it.
Yeah :(.
> I'm not sure what to do then. Try some even worse hack and leave that
> in for a couple of years to give upstream KVM a chance to trickle down.
>
> Thanks,
> Nick
>
--
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
signature.asc
Description: PGP signature
Re: [PATCH 1/2] spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall, David Gibson, 2022/02/14