All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: x86: Apply runtime updates to current CPUID during KVM_SET_CPUID{,2}
Date: Tue, 2 Dec 2025 13:02:52 +0100	[thread overview]
Message-ID: <20251202130252.1f799692@imammedo> (raw)
In-Reply-To: <20251202015049.1167490-2-seanjc@google.com>

On Mon,  1 Dec 2025 17:50:48 -0800
Sean Christopherson <seanjc@google.com> wrote:

> When handling KVM_SET_CPUID{,2}, do runtime CPUID updates on the vCPU's
> current CPUID (and caps) prior to swapping in the incoming CPUID state so
> that KVM doesn't lose pending updates if the incoming CPUID is rejected,
> and to prevent a false failure on the equality check.
> 
> Note, runtime updates are unconditionally performed on the incoming/new
> CPUID (and associated caps), i.e. clearing the dirty flag won't negatively
> affect the new CPUID.
> 
> Fixes: 93da6af3ae56 ("KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation")
> Reported-by: Igor Mammedov <imammedo@redhat.com>
> Closes: https://lore.kernel.org/all/20251128123202.68424a95@imammedo
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Acked-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>

> ---
>  arch/x86/kvm/cpuid.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index d563a948318b..88a5426674a1 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -509,11 +509,18 @@ static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
>  	u32 vcpu_caps[NR_KVM_CPU_CAPS];
>  	int r;
>  
> +	/*
> +	 * Apply pending runtime CPUID updates to the current CPUID entries to
> +	 * avoid false positives due to mismatches on KVM-owned feature flags.
> +	 */
> +	if (vcpu->arch.cpuid_dynamic_bits_dirty)
> +		kvm_update_cpuid_runtime(vcpu);
> +
>  	/*
>  	 * Swap the existing (old) entries with the incoming (new) entries in
>  	 * order to massage the new entries, e.g. to account for dynamic bits
> -	 * that KVM controls, without clobbering the current guest CPUID, which
> -	 * KVM needs to preserve in order to unwind on failure.
> +	 * that KVM controls, without losing the current guest CPUID, which KVM
> +	 * needs to preserve in order to unwind on failure.
>  	 *
>  	 * Similarly, save the vCPU's current cpu_caps so that the capabilities
>  	 * can be updated alongside the CPUID entries when performing runtime


  reply	other threads:[~2025-12-02 12:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  1:50 [PATCH 0/2] KVM: x86: Do runtime updates during KVM_SET_CPUID2 Sean Christopherson
2025-12-02  1:50 ` [PATCH 1/2] KVM: x86: Apply runtime updates to current CPUID during KVM_SET_CPUID{,2} Sean Christopherson
2025-12-02 12:02   ` Igor Mammedov [this message]
2025-12-02  1:50 ` [PATCH 2/2] KVM: selftests: Add a CPUID testcase for KVM_SET_CPUID2 with runtime updates Sean Christopherson
2025-12-05 16:59 ` [PATCH 0/2] KVM: x86: Do runtime updates during KVM_SET_CPUID2 Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251202130252.1f799692@imammedo \
    --to=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.