No functional change.
x86_init.hyper.x2apic_available is used only in try_to_enable_x2apic to check if
x2apic needs to be disabled if interrupt remapping support isn't present. But
the name x2apic_available doesn't reflect that usage.
This is what x2apic_available is set to for various hypervisors:
acrn boot_cpu_has(X86_FEATURE_X2APIC)
mshyperv boot_cpu_has(X86_FEATURE_X2APIC)
xen boot_cpu_has(X86_FEATURE_X2APIC) or false
vmware vmware_legacy_x2apic_available
kvm kvm_cpuid_base() != 0
jailhouse x2apic_enabled()
bhyve true
default false
Bare metal and vmware correctly check if x2apic is available without interrupt
remapping. The rest of them check if x2apic is enabled/supported, and kvm just
checks if the kernel is running on kvm. The other hypervisors may have to have
their checks audited.
Also fix the backwards pr_info message printed on disabling x2apic because of
lack of irq remapping support.
Compile tested with all the hypervisor guest support enabled.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
arch/x86/include/asm/x86_init.h | 4 ++--
arch/x86/kernel/apic/apic.c | 4 ++--
arch/x86/kernel/cpu/acrn.c | 2 +-
arch/x86/kernel/cpu/bhyve.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 2 +-
arch/x86/kernel/cpu/vmware.c | 2 +-
arch/x86/kernel/jailhouse.c | 2 +-
arch/x86/kernel/kvm.c | 2 +-
arch/x86/kernel/x86_init.c | 12 ++++++------
arch/x86/xen/enlighten_hvm.c | 4 ++--
10 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 6c8a6ead84f6..b270d9eed755 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -116,7 +116,7 @@ struct x86_init_pci {
* struct x86_hyper_init - x86 hypervisor init functions
* @init_platform: platform setup
* @guest_late_init: guest late init
- * @x2apic_available: X2APIC detection
+ * @x2apic_without_ir_available: is x2apic available without irq remap?
* @msi_ext_dest_id: MSI supports 15-bit APIC IDs
* @init_mem_mapping: setup early mappings during init_mem_mapping()
* @init_after_bootmem: guest init after boot allocator is finished
@@ -124,7 +124,7 @@ struct x86_init_pci {
struct x86_hyper_init {
void (*init_platform)(void);
void (*guest_late_init)(void);
- bool (*x2apic_available)(void);
+ bool (*x2apic_without_ir_available)(void);
bool (*msi_ext_dest_id)(void);
void (*init_mem_mapping)(void);
void (*init_after_bootmem)(void);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index cc64d61f82cf..8820b631f8a2 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1836,8 +1836,8 @@ static __init void try_to_enable_x2apic(int remap_mode)
* Using X2APIC without IR is not architecturally supported
* on bare metal but may be supported in guests.
*/
- if (!x86_init.hyper.x2apic_available()) {
- pr_info("x2apic: IRQ remapping doesn't support X2APIC mode\n");
+ if (!x86_init.hyper.x2apic_without_ir_available()) {
+ pr_info("x2apic: Not supported without IRQ remapping\n");
x2apic_disable();
return;
}
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 2c5b51aad91a..9204b98d4786 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -77,5 +77,5 @@ const __initconst struct hypervisor_x86 x86_hyper_acrn = {
.detect = acrn_detect,
.type = X86_HYPER_ACRN,
.init.init_platform = acrn_init_platform,
- .init.x2apic_available = acrn_x2apic_available,
+ .init.x2apic_without_ir_available = acrn_x2apic_available,
};
diff --git a/arch/x86/kernel/cpu/bhyve.c b/arch/x86/kernel/cpu/bhyve.c
index f1a8ca3dd1ed..91a90a7459ce 100644
--- a/arch/x86/kernel/cpu/bhyve.c
+++ b/arch/x86/kernel/cpu/bhyve.c
@@ -61,6 +61,6 @@ const struct hypervisor_x86 x86_hyper_bhyve __refconst = {
.name = "Bhyve",
.detect = bhyve_detect,
.init.init_platform = x86_init_noop,
- .init.x2apic_available = bhyve_x2apic_available,
+ .init.x2apic_without_ir_available = bhyve_x2apic_available,
.init.msi_ext_dest_id = bhyve_ext_dest_id,
};
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 579fb2c64cfd..61458855094a 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -760,7 +760,7 @@ const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
.name = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
.type = X86_HYPER_MS_HYPERV,
- .init.x2apic_available = ms_hyperv_x2apic_available,
+ .init.x2apic_without_ir_available = ms_hyperv_x2apic_available,
.init.msi_ext_dest_id = ms_hyperv_msi_ext_dest_id,
.init.init_platform = ms_hyperv_init_platform,
.init.guest_late_init = ms_hyperv_late_init,
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index cb3f900c46fc..46d325818797 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -585,7 +585,7 @@ const __initconst struct hypervisor_x86 x86_hyper_vmware = {
.detect = vmware_platform,
.type = X86_HYPER_VMWARE,
.init.init_platform = vmware_platform_setup,
- .init.x2apic_available = vmware_legacy_x2apic_available,
+ .init.x2apic_without_ir_available = vmware_legacy_x2apic_available,
#ifdef CONFIG_AMD_MEM_ENCRYPT
.runtime.sev_es_hcall_prepare = vmware_sev_es_hcall_prepare,
.runtime.sev_es_hcall_finish = vmware_sev_es_hcall_finish,
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 9e9a591a5fec..84a0bbe15989 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -291,6 +291,6 @@ const struct hypervisor_x86 x86_hyper_jailhouse __refconst = {
.name = "Jailhouse",
.detect = jailhouse_detect,
.init.init_platform = jailhouse_init_platform,
- .init.x2apic_available = jailhouse_x2apic_available,
+ .init.x2apic_without_ir_available = jailhouse_x2apic_available,
.ignore_nopv = true,
};
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 37dc8465e0f5..709eba87d58e 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -1042,7 +1042,7 @@ const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.detect = kvm_detect,
.type = X86_HYPER_KVM,
.init.guest_late_init = kvm_guest_init,
- .init.x2apic_available = kvm_para_available,
+ .init.x2apic_without_ir_available = kvm_para_available,
.init.msi_ext_dest_id = kvm_msi_ext_dest_id,
.init.init_platform = kvm_init_platform,
#if defined(CONFIG_AMD_MEM_ENCRYPT)
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index ebefb77c37bb..9ddf8c901ac6 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -112,12 +112,12 @@ struct x86_init_ops x86_init __initdata = {
},
.hyper = {
- .init_platform = x86_init_noop,
- .guest_late_init = x86_init_noop,
- .x2apic_available = bool_x86_init_noop,
- .msi_ext_dest_id = bool_x86_init_noop,
- .init_mem_mapping = x86_init_noop,
- .init_after_bootmem = x86_init_noop,
+ .init_platform = x86_init_noop,
+ .guest_late_init = x86_init_noop,
+ .x2apic_without_ir_available = bool_x86_init_noop,
+ .msi_ext_dest_id = bool_x86_init_noop,
+ .init_mem_mapping = x86_init_noop,
+ .init_after_bootmem = x86_init_noop,
},
.acpi = {
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index fe57ff85d004..42f3d21f313d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -311,7 +311,7 @@ static uint32_t __init xen_platform_hvm(void)
* detect PVH and panic there.
*/
h->init_platform = x86_init_noop;
- h->x2apic_available = bool_x86_init_noop;
+ h->x2apic_without_ir_available = bool_x86_init_noop;
h->init_mem_mapping = x86_init_noop;
h->init_after_bootmem = x86_init_noop;
h->guest_late_init = xen_hvm_guest_late_init;
@@ -325,7 +325,7 @@ struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
.detect = xen_platform_hvm,
.type = X86_HYPER_XEN_HVM,
.init.init_platform = xen_hvm_guest_init,
- .init.x2apic_available = xen_x2apic_available,
+ .init.x2apic_without_ir_available = xen_x2apic_available,
.init.init_mem_mapping = xen_hvm_init_mem_mapping,
.init.guest_late_init = xen_hvm_guest_late_init,
.init.msi_ext_dest_id = msi_ext_dest_id,
--
2.43.0On 2/2/2026 1:51 AM, Shashank Balaji wrote: > No functional change. > > x86_init.hyper.x2apic_available is used only in try_to_enable_x2apic to check if > x2apic needs to be disabled if interrupt remapping support isn't present. But > the name x2apic_available doesn't reflect that usage. > I don't understand the premise of this patch. Shouldn't the variable name reflect what is stored rather than how it is used? > This is what x2apic_available is set to for various hypervisors: > > acrn boot_cpu_has(X86_FEATURE_X2APIC) > mshyperv boot_cpu_has(X86_FEATURE_X2APIC) > xen boot_cpu_has(X86_FEATURE_X2APIC) or false > vmware vmware_legacy_x2apic_available > kvm kvm_cpuid_base() != 0 > jailhouse x2apic_enabled() > bhyve true > default false > If both interrupt remapping and x2apic are enabled, what would the name x2apic_without_ir_available signify? A value of "true" would mean x2apic is available without IR. But that would be inaccurate for most hypervisors. A value of "false" could be interpreted as x2apic is not available, which is also inaccurate. To me, x2apic_available makes more sense than x2apic_without_ir_available based on the values being set by the hypervisors. > Bare metal and vmware correctly check if x2apic is available without interrupt > remapping. The rest of them check if x2apic is enabled/supported, and kvm just > checks if the kernel is running on kvm. The other hypervisors may have to have > their checks audited. > AFAIU, the value on bare metal is set to false because this is a hypervisor specific variable. Perhaps I have misunderstood something?
On Thu, Feb 05, 2026 at 04:10:37PM -0800, Sohil Mehta wrote:
> On 2/2/2026 1:51 AM, Shashank Balaji wrote:
> > No functional change.
> >
> > x86_init.hyper.x2apic_available is used only in try_to_enable_x2apic to check if
> > x2apic needs to be disabled if interrupt remapping support isn't present. But
> > the name x2apic_available doesn't reflect that usage.
> >
>
> I don't understand the premise of this patch. Shouldn't the variable
> name reflect what is stored rather than how it is used?
Sorry about the confusion, I should have used '()'.
x86_init.hyper.x2apic_available() is called only in
try_to_enable_x2apic(). Here's the relevant snippet:
static __init void try_to_enable_x2apic(int remap_mode)
{
if (x2apic_state == X2APIC_DISABLED)
return;
if (remap_mode != IRQ_REMAP_X2APIC_MODE) {
u32 apic_limit = 255;
/*
* Using X2APIC without IR is not architecturally supported
* on bare metal but may be supported in guests.
*/
if (!x86_init.hyper.x2apic_available()) {
pr_info("x2apic: IRQ remapping doesn't support X2APIC mode\n");
x2apic_disable();
return;
}
So the question being asked is, "can x2apic be used without IR?", but
the name "x2apic_available" signals "is x2apic available?". I found this
confusing while going through the source.
Most hypervisors set their x2apic_available() implementation to
essentially return if the CPU supports x2apic or not, which is valid
given the name "x2apic_available", but x2apic availability is not what's in
question at the callsite.
> > This is what x2apic_available is set to for various hypervisors:
> >
> > acrn boot_cpu_has(X86_FEATURE_X2APIC)
> > mshyperv boot_cpu_has(X86_FEATURE_X2APIC)
> > xen boot_cpu_has(X86_FEATURE_X2APIC) or false
> > vmware vmware_legacy_x2apic_available
> > kvm kvm_cpuid_base() != 0
> > jailhouse x2apic_enabled()
> > bhyve true
> > default false
> >
>
> If both interrupt remapping and x2apic are enabled, what would the name
> x2apic_without_ir_available signify?
If IR is enabled, then the branch to call x2apic_available() wouldn't be taken :)
So the meaning of x2apic_without_ir_available wouldn't be relevant
anymore.
> A value of "true" would mean x2apic is available without IR. But that
> would be inaccurate for most hypervisors. A value of "false" could be
> interpreted as x2apic is not available, which is also inaccurate.
>
> To me, x2apic_available makes more sense than
> x2apic_without_ir_available based on the values being set by the
> hypervisors.
I agree with you, and I think therein lies the problem. Most hypervisors
are answering the broader question "is x2apic available?", so the name
"x2apic_available" makes sense.
I think further work is required to check if various implementations of
x2apic_available() also need to be changed to reflect the "x2apic
without IR?" semantic, but I don't know enough to do that myself. Maybe
I should have added TODOs above the implementations.
I would like the feedback of the virt folks too on all this, maybe I'm
misinterpreting what's going on here.
> > Bare metal and vmware correctly check if x2apic is available without interrupt
> > remapping. The rest of them check if x2apic is enabled/supported, and kvm just
> > checks if the kernel is running on kvm. The other hypervisors may have to have
> > their checks audited.
> >
> AFAIU, the value on bare metal is set to false because this is a
> hypervisor specific variable. Perhaps I have misunderstood something?
© 2016 - 2026 Red Hat, Inc.