All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Venkatesh Srinivas <venkateshs@google.com>,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Venkatesh Srinivas <venkateshs@chromium.org>
Subject: Re: [PATCH] KVM: SVM: Propagate Translation Cache Extensions to the guest
Date: Fri, 6 Mar 2026 16:56:19 -0800	[thread overview]
Message-ID: <aat3s9EjKB_IsQQf@google.com> (raw)
In-Reply-To: <CAO9r8zO+sTttrKscx+9Sr+TECLrb5rHFTPThHYZG_e1qKSo+Cg@mail.gmail.com>

On Fri, Mar 06, 2026, Yosry Ahmed wrote:
> > Hrm, I think we should handle all of the kvm_enable_efer_bits() calls that are
> > conditioned only on CPU support in common code.  While it's highly unlikely Intel
> > CPUs will ever support more EFER-based features, if they do, then KVM will
> > over-report support since kvm_initialize_cpu_caps() will effectively enable the
> > feature, but VMX won't enable the corresponding EFER bit.
> >
> > I can't think anything that will go sideways if we rely purely on KVM caps, so
> > get to something like this as prep work, and then land TCE in common x86?
> 
> Taking a second look here, doesn't this break the changes introduced
> by commit 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID checks
> for host-initiated writes")? Userspace writes may fail if the
> corresponding CPUID feature is not enabled.

No, because kvm_cpu_cap_has() == boot_cpu_has() filtered by what KVM supports.
All of these EFER updates subtly rely on KVM enabling the associated CPUID
feature in kvm_set_cpu_caps().

If we used guest_cpu_cap_has(), then yes, that would be a problem.

  reply	other threads:[~2026-03-07  0:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06  0:23 [PATCH] KVM: SVM: Propagate Translation Cache Extensions to the guest Yosry Ahmed
2026-03-06 16:19 ` Sean Christopherson
2026-03-06 16:37   ` Yosry Ahmed
2026-03-06 22:40     ` Sean Christopherson
2026-03-06 23:01   ` Yosry Ahmed
2026-03-07  0:56     ` Sean Christopherson [this message]
2026-03-07  0:58       ` Yosry Ahmed

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=aat3s9EjKB_IsQQf@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=venkateshs@chromium.org \
    --cc=venkateshs@google.com \
    --cc=yosry@kernel.org \
    /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.