qemu-ppc
[Top][All Lists]
Advanced

[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: Nicholas Piggin
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 11:46:58 +1000

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? :(

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]