Re: [PATCH v2 4/7] KVM: x86: Add a per-vendor callback to setup EFER caps

[Sean Christopherson]

On Wed, Jul 08, 2026, Yosry Ahmed wrote:
> On Wed, Jul 8, 2026 at 7:01 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >
> > On Tue, Jul 07, 2026, Yosry Ahmed wrote:
> > > On Tue, Jul 7, 2026 at 2:56 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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().
> 
> Right, I missed this. kvm_is_configuring_cpu_caps is neat. I wonder if
> we can make that an enum with values {UNINIT, CONFIGURING,
> INITIALIZED}, then we can be more paranoid and WARN if the the state
> isn't INITIALIZED in kvm_setup_efer_caps(). That might be too paranoid
> though.

I thought about trying to do something like that too, and mostly landed on "too
paranoid".  Or rather, landed on "mostly just shifts where the bugs will be".
E.g. kvm_setup_efer_caps() needs to run after kvm_cpu_caps are configured, or
more specificaly, before ops->hardware_setup().  But supported_{xcr0,xss} need
to be initialized before ops->hardware_setup(), so that KVM can manipulate the
support bits at the same time kvm_cpu_caps are updated.  And so adding one-off
WARNs still requires on having a priori knowledge of exactly where in the
bootstrapping process the code needs to run, i.e. we still have to "manually"
select the right stage of kvm_is_configuring_cpu_caps.

What _would_ scale a little better would be to have kvm_cpu_cap_get() WARN if
kvm_is_configuring_cpu_caps isn't INITIALIZED, but I'm hesitant to do that because
it'll pollute KVM with WARNs just to detect rare bugs that really should be caught
during initial development anyways.