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;
 
 	/*
 	 * Disable IPI virtualization for AMD Family 17h CPUs (Zen1 and Zen2)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 3bcb88b2e617..d4643dce7c91 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -5354,15 +5354,13 @@ static __init int svm_hardware_setup(void)
 			goto err;
 	}
 
-	enable_apicv = avic = avic && avic_hardware_setup();
+	enable_apicv = avic = avic && avic_hardware_setup(&svm_x86_ops);
 
 	if (!enable_apicv) {
 		enable_ipiv = false;
 		svm_x86_ops.vcpu_blocking = NULL;
 		svm_x86_ops.vcpu_unblocking = NULL;
 		svm_x86_ops.vcpu_get_apicv_inhibit_reasons = NULL;
-	} else if (!x2avic_enabled) {
-		svm_x86_ops.allow_apicv_in_x2apic_without_x2apic_virtualization = true;
 	}
 
 	if (vls) {
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 1e612bbfd36d..811513c8b566 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -48,7 +48,6 @@ extern bool npt_enabled;
 extern int nrips;
 extern int vgif;
 extern bool intercept_smi;
-extern bool x2avic_enabled;
 extern bool vnmi;
 extern int lbrv;
 
@@ -800,7 +799,7 @@ extern struct kvm_x86_nested_ops svm_nested_ops;
 	BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_TOO_BIG)	\
 )
 
-bool avic_hardware_setup(void);
+bool __init avic_hardware_setup(struct kvm_x86_ops *svm_ops);
 int avic_ga_log_notifier(u32 ga_tag);
 void avic_vm_destroy(struct kvm *kvm);
 int avic_vm_init(struct kvm *kvm);
-- 
2.51.0.470.ga7dc726c21-goog

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. 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?

Otherwise, for this patch:
Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>


- Naveen

+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.

>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.

I think passing in ops to vendor-specific helpers looks a bit indirect as the
parameter should always be svm_x86_ops for AMD or vt_x86_ops for Intel.

I slightly prefer making {svm,vt}_x86_ops globally visible.

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