qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] KVM: x86: believe what KVM says about WAITPKG


From: Maxim Levitsky
Subject: Re: [PATCH] KVM: x86: believe what KVM says about WAITPKG
Date: Tue, 30 Jun 2020 19:07:36 +0300
User-agent: Evolution 3.34.4 (3.34.4-1.fc31)

On Tue, 2020-06-30 at 11:11 -0400, Paolo Bonzini wrote:
> Currently, QEMU is overriding KVM_GET_SUPPORTED_CPUID's answer for
> the WAITPKG bit depending on the "-overcommit cpu-pm" setting.  This is a
> bad idea because it does not even check if the host supports it, but it
> can be done in x86_cpu_realizefn just like we do for the MONITOR bit.
> 
> This patch moves it there, of course making it conditional on host
> availability which is not being done for the MONITOR bit.  It also makes
> MONITOR conditional, though not strictly necessary, so that the code
> looks the same for both and generally more natural.
> 
> Cc: qemu-stable@nongnu.org
> Reported-by: Maxim Levitsky <mlevitsk@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  target/i386/cpu.c | 5 ++++-
>  target/i386/kvm.c | 6 ------
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index c44cc510e1..0de8dc569a 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6535,7 +6535,10 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>          if (enable_cpu_pm) {
>              host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx,
>                         &cpu->mwait.ecx, &cpu->mwait.edx);
> -            env->features[FEAT_1_ECX] |= CPUID_EXT_MONITOR;
> +            env->features[FEAT_1_ECX] |=
> +                x86_cpu_get_supported_feature_word(FEAT_1_ECX, 
> cpu->migratable) & CPUID_EXT_MONITOR;
> +            env->features[FEAT_7_0_ECX] |=
> +                x86_cpu_get_supported_feature_word(FEAT_7_0_ECX, 
> cpu->migratable) & CPUID_7_0_ECX_WAITPKG;
> 
After some digging I now understand that these are defaults for 'host/max', 
which can later be overriden
by the user, so this is correct assuming that we indeed can trust 
'x86_cpu_get_supported_feature_word'.


>          }
>          if (kvm_enabled() && cpu->ucode_rev == 0) {
>              cpu->ucode_rev = kvm_arch_get_supported_msr_feature(kvm_state,
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 2b6b7443d2..c9ef27080d 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -411,12 +411,6 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
> uint32_t function,
>          if (host_tsx_blacklisted()) {
>              ret &= ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE);
>          }
> -    } else if (function == 7 && index == 0 && reg == R_ECX) {
> -        if (enable_cpu_pm) {
> -            ret |= CPUID_7_0_ECX_WAITPKG;
> -        } else {
> -            ret &= ~CPUID_7_0_ECX_WAITPKG;
> -        }

I think we need to keep some form of this hack, since the kernel doesn't report 
CPUID_7_0_ECX_WAITPKG via
KVM_GET_SUPPORTED_CPUID, so for this to work, we need to fix the kernel to 
report it. 
But to support older kernels that don't report this bit, we might still need 
this.
What do you think?

Note that kvm_arch_get_supported_cpuid also has a override for what KVM reports 
about CPUID_EXT_MONITOR
via KVM_GET_SUPPORTED_CPUID when cpu_pm=on and also does this without checking 
any conditions,
and it works because MWAIT is very old feature, and I guess it was the 
inspiration for the above override
that we are trying to remove.

Kernel sadly masks both MWAIT and WAITPKG in KVM_GET_SUPPORTED_CPUID currently
(it is in kvm_set_cpu_caps)


>      } else if (function == 7 && index == 0 && reg == R_EDX) {
>          /*
>           * Linux v4.17-v4.20 incorrectly return ARCH_CAPABILITIES on SVM 
> hosts.

Best regards,
        Maxim Levitsky




reply via email to

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