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>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/7] KVM: x86: Add a per-vendor callback to setup EFER caps
Date: Wed, 8 Jul 2026 07:01:53 -0700	[thread overview]
Message-ID: <ak5YUdHyA36ogsvD@google.com> (raw)
In-Reply-To: <CAO9r8zPdJHE=ztF8enA58EbR3iy4_Urhc93RkHiS2HkEsDkS_A@mail.gmail.com>

On Tue, Jul 07, 2026, Yosry Ahmed wrote:
> On Tue, Jul 7, 2026 at 2:56 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Jul 06, 2026, Yosry Ahmed wrote:
> > > Move handling EFER.SVME and EFER.LMSLE from hardware setup to a new
> > > optional per-vendor callback invoked from kvm_setup_efer_caps(). This
> > > centralizes allowed EFER bits handling to kvm_setup_efer_caps(),
> > > facilitating following changes to move efer_reserved_bits into kvm_caps.
> > >
> > > Move the call to kvm_setup_efer_caps() after per-vendor ops are
> > > initialized.
> >
> > Why?
> >
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index a0b2c40d93c21..a297a77469b38 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -6903,6 +6903,8 @@ static void kvm_setup_efer_caps(void)
> > >
> > >       if (kvm_cpu_cap_has(X86_FEATURE_AUTOIBRS))
> > >               kvm_enable_efer_bits(EFER_AUTOIBRS);
> > > +
> > > +     kvm_x86_call(setup_efer_caps)();
> >
> > I would rather move the togging to kvm_setup_efer_caps(), e.g.
> 
> I didn't do it this way because it creates a dependency on SVM setting
> the X86_FEATURE_SVM cap before kvm_setup_efer_caps() is called.

For all intents and purposes, that dependency already exists due to the
X86_FEATURE_{NX,FXSR_OPT,AUTOIBRS} checks.  And thanks to kvm_is_configuring_cpu_caps,
it's "impossible" for those caps to be toggled outside of svm_set_cpu_caps().

> e.g. it would break if the call to kvm_setup_efer_caps() is moved
> before the vendor-specific hardware_setup(). 

As above, that would break for other reasons.

> Maybe that's fine, but it just seemed like the dependency can be easily
> avoided here by adding a new vendor-specific callback.

No, all it does is change what can go wrong.   E.g. if KVM cleared "nested" in
svm_hardware_setup(), which is *very* realistic given that we carry an internal
patch to disable nested if TDP is disabled, then hoisting kvm_setup_efer_caps()
above ops->hardware_setup() would still break (even ignoring the above issues).

  reply	other threads:[~2026-07-08 14:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 19:54 [PATCH v2 0/7] KVM: x86: EFER validity fixes and cleanups Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 1/7] KVM: x86: Check EFER validity on KVM_SET_SREGS* Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 2/7] KVM: SVM: Disallow EFER.SVME and EFER.LSMLE if nested is disabled Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 3/7] KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 4/7] KVM: x86: Add a per-vendor callback to setup EFER caps Yosry Ahmed
2026-07-07 21:56   ` Sean Christopherson
2026-07-07 22:29     ` Yosry Ahmed
2026-07-08 14:01       ` Sean Christopherson [this message]
2026-07-08 19:12         ` Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 5/7] KVM: x86: Reverse the polarity of efer_reserved_bits Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 6/7] KVM: x86: Move supported EFER bits to kvm_caps Yosry Ahmed
2026-07-06 20:05   ` sashiko-bot
2026-07-06 20:27     ` Yosry Ahmed
2026-07-06 19:54 ` [PATCH v2 7/7] KVM: selftests: Extend set_sregs test to cover EFER 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=ak5YUdHyA36ogsvD@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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.