Re: [PATCH v3 2/6] KVM: SVM: Update "APICv in x2APIC without x2AVIC" in avic.c, not svm.c

[Sean Christopherson <seanjc@google.com>]

+Intel folks (question at the bottom regarding vt_x86_ops)

On Fri, Sep 19, 2025, Naveen N Rao wrote:
> On Thu, Sep 18, 2025 at 05:21:32PM -0700, Sean Christopherson wrote:
> > Set the "allow_apicv_in_x2apic_without_x2apic_virtualization" flag as part
> > of avic_hardware_setup() instead of handling in svm_hardware_setup(), and
> > make x2avic_enabled local to avic.c (setting the flag was the only use in
> > svm.c).
> > 
> > Opportunistically tag avic_hardware_setup() with __init to make it clear
> > that nothing untoward is happening with svm_x86_ops.
> > 
> > No functional change intended (aside from the side effects of tagging
> > avic_hardware_setup() with __init).
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/svm/avic.c | 6 ++++--
> >  arch/x86/kvm/svm/svm.c  | 4 +---
> >  arch/x86/kvm/svm/svm.h  | 3 +--
> >  3 files changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> > index 478a18208a76..683411442476 100644
> > --- a/arch/x86/kvm/svm/avic.c
> > +++ b/arch/x86/kvm/svm/avic.c
> > @@ -77,7 +77,7 @@ static DEFINE_HASHTABLE(svm_vm_data_hash, SVM_VM_DATA_HASH_BITS);
> >  static u32 next_vm_id = 0;
> >  static bool next_vm_id_wrapped = 0;
> >  static DEFINE_SPINLOCK(svm_vm_data_hash_lock);
> > -bool x2avic_enabled;
> > +static bool x2avic_enabled;
> >  
> >  
> >  static void avic_set_x2apic_msr_interception(struct vcpu_svm *svm,
> > @@ -1147,7 +1147,7 @@ void avic_vcpu_unblocking(struct kvm_vcpu *vcpu)
> >   * - Hypervisor can support both xAVIC and x2AVIC in the same guest.
> >   * - The mode can be switched at run-time.
> >   */
> > -bool avic_hardware_setup(void)
> > +bool __init avic_hardware_setup(struct kvm_x86_ops *svm_ops)
> >  {
> >  	if (!npt_enabled)
> >  		return false;
> > @@ -1182,6 +1182,8 @@ bool avic_hardware_setup(void)
> >  	x2avic_enabled = boot_cpu_has(X86_FEATURE_X2AVIC);
> >  	if (x2avic_enabled)
> >  		pr_info("x2AVIC enabled\n");
> > +	else
> > +		svm_ops->allow_apicv_in_x2apic_without_x2apic_virtualization = true;
> 
> I'm not entirely convinced that this is better since svm_x86_ops fields 
> are now being updated outside of svm.c.

That doesn't bother me, e.g. the pmu_ops buried in svm_x86_ops come from
arch/x86/kvm/svm/pmu.c.  Eww, and arch/x86/kvm/svm/svm_onhyperv.h already accesses
svm_x86_ops, but in the grossest way possible.

FWIW, I don't love splitting the APIC virtualization updates between
svm_hardware_setup() and avic_hardware_setup(), but overall I do think that's the
best balance between bundling all code together and making it easy(ish) for
readers to figure out what's going on.

> But, I do see your point about  limiting x2avic_enabled to avic.c
> 
> Would it be better to name this field as svm_x86_ops here too, so it is 
> at least easy to grep and find?

I didn't want to create a potential variable shadowing "problem".  The alternative
would be to expose svm_x86_ops via svm.h.  That's not my first choice, but it's
the route that was taken for the TDX vs. VMX split (vt_init_ops and vt_x86_ops
are globally visible, even though they _could_ have been explicitly passed in
as parameters to {tdx,vmx}_hardware_setup()).

Question then.  Does anyone have a preference/opinion between explicitly passing
in ops to vendor specific helpers, vs. making {svm,vt}_x86_ops globally visible?

I don't love creating "hidden" dependencies, in quotes because in this case it's
relatively easy to establish that the setup() helpers modify {svm,vt}_x86_ops,
i.e. surprises should be rare.

On the other hand, I do agree it's helpful to be able to see exactly where
{svm,vt}_x86_ops are updated.

And most importantly, I want to be consistent between VMX and SVM, i.e. I want
to pick one and stick with it.