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-googOn 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.
© 2016 - 2025 Red Hat, Inc.