lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b747a9dacb0ead3d16c71192df8a61e8545d0e6.camel@redhat.com>
Date: Thu, 04 Jul 2024 21:51:19 -0400
From: Maxim Levitsky <mlevitsk@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
 <pbonzini@...hat.com>,  Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, Hou Wenlong
 <houwenlong.hwl@...group.com>, Kechen Lu <kechenl@...dia.com>, Oliver Upton
 <oliver.upton@...ux.dev>, Binbin Wu <binbin.wu@...ux.intel.com>, Yang
 Weijiang <weijiang.yang@...el.com>, Robert Hoo <robert.hoo.linux@...il.com>
Subject: Re: [PATCH v2 29/49] KVM: x86: Remove unnecessary caching of KVM's
 PV CPUID base

On Fri, 2024-05-17 at 10:39 -0700, Sean Christopherson wrote:
> Now that KVM only searches for KVM's PV CPUID base when userspace sets
> guest CPUID, drop the cache and simply do the search every time.
> 
> Practically speaking, this is a nop except for situations where userspace
> sets CPUID _after_ running the vCPU, which is anything but a hot path,
> e.g. QEMU does so only when hotplugging a vCPU.  And on the flip side,
> caching guest CPUID information, especially information that is used to
> query/modify _other_ CPUID state, is inherently dangerous as it's all too
> easy to use stale information, i.e. KVM should only cache CPUID state when
> the performance and/or programming benefits justify it.
> 
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
>  arch/x86/include/asm/kvm_host.h |  1 -
>  arch/x86/kvm/cpuid.c            | 34 +++++++--------------------------
>  2 files changed, 7 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index aabf1648a56a..3003e99155e7 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -858,7 +858,6 @@ struct kvm_vcpu_arch {
>  
>  	int cpuid_nent;
>  	struct kvm_cpuid_entry2 *cpuid_entries;
> -	struct kvm_hypervisor_cpuid kvm_cpuid;
>  	bool is_amd_compatible;
>  
>  	/*
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 93a7399dc0db..7290f91c422c 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -269,28 +269,16 @@ static struct kvm_hypervisor_cpuid kvm_get_hypervisor_cpuid(struct kvm_vcpu *vcp
>  					  vcpu->arch.cpuid_nent, sig);
>  }
>  
> -static struct kvm_cpuid_entry2 *__kvm_find_kvm_cpuid_features(struct kvm_cpuid_entry2 *entries,
> -							      int nent, u32 kvm_cpuid_base)
> -{
> -	return cpuid_entry2_find(entries, nent, kvm_cpuid_base | KVM_CPUID_FEATURES,
> -				 KVM_CPUID_INDEX_NOT_SIGNIFICANT);
> -}
> -
> -static struct kvm_cpuid_entry2 *kvm_find_kvm_cpuid_features(struct kvm_vcpu *vcpu)
> -{
> -	u32 base = vcpu->arch.kvm_cpuid.base;
> -
> -	if (!base)
> -		return NULL;
> -
> -	return __kvm_find_kvm_cpuid_features(vcpu->arch.cpuid_entries,
> -					     vcpu->arch.cpuid_nent, base);
> -}
> -
>  static u32 kvm_apply_cpuid_pv_features_quirk(struct kvm_vcpu *vcpu)
>  {
> -	struct kvm_cpuid_entry2 *best = kvm_find_kvm_cpuid_features(vcpu);
> +	struct kvm_hypervisor_cpuid kvm_cpuid;
> +	struct kvm_cpuid_entry2 *best;
>  
> +	kvm_cpuid = kvm_get_hypervisor_cpuid(vcpu, KVM_SIGNATURE);
> +	if (!kvm_cpuid.base)
> +		return 0;
> +
> +	best = kvm_find_cpuid_entry(vcpu, kvm_cpuid.base | KVM_CPUID_FEATURES);
>  	if (!best)
>  		return 0;
>  
> @@ -491,13 +479,6 @@ static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
>  	 * whether the supplied CPUID data is equal to what's already set.
>  	 */
>  	if (kvm_vcpu_has_run(vcpu)) {
> -		/*
> -		 * Note, runtime CPUID updates may consume other CPUID-driven
> -		 * vCPU state, e.g. KVM or Xen CPUID bases.  Updating runtime
> -		 * state before full CPUID processing is functionally correct
> -		 * only because any change in CPUID is disallowed, i.e. using
> -		 * stale data is ok because KVM will reject the change.
> -		 */
Hi,

Any reason why this comment was removed? As I said earlier in the review.
It might make sense to replace this comment with a comment reflecting on why
we need to call kvm_update_cpuid_runtime, that is solely to allow old == new
compare to succeed.

>  		kvm_update_cpuid_runtime(vcpu);
>  		kvm_apply_cpuid_pv_features_quirk(vcpu);
>  
> @@ -519,7 +500,6 @@ static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
>  	if (r)
>  		goto err;
>  
> -	vcpu->arch.kvm_cpuid = kvm_get_hypervisor_cpuid(vcpu, KVM_SIGNATURE);
>  #ifdef CONFIG_KVM_XEN
>  	vcpu->arch.xen.cpuid = kvm_get_hypervisor_cpuid(vcpu, XEN_SIGNATURE);
>  #endif



Best regards,
	Maxim Levitsky


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ