* [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram
@ 2026-02-02 9:51 Shashank Balaji
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-02 9:51 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird, stable
On resume from s2ram, a defconfig kernel gets into a state where the x2apic
hardware state and the kernel's perceived state are different.
On boot, x2apic is enabled by the firmware, and then the kernel does the
following (relevant lines from dmesg):
[ 0.000381] x2apic: enabled by BIOS, switching to x2apic ops
[ 0.009939] APIC: Switched APIC routing to: cluster x2apic
[ 0.095151] x2apic: IRQ remapping doesn't support X2APIC mode
[ 0.095154] x2apic disabled
[ 0.095551] APIC: Switched APIC routing to: physical flat
defconfig has CONFIG_IRQ_REMAP=n, which leads to x2apic being disabled,
because on bare metal, x2apic has an architectural dependence on interrupt
remapping.
While resuming from s2ram, x2apic is enabled again by the firmware, but
the kernel continues using the physical flat apic routing. This causes a
hang-up and no console output.
Patch 1 fixes this in lapic_resume by disabling x2apic when the kernel expects
it to be disabled.
Patch 2 enables CONFIG_IRQ_REMAP in defconfig so that defconfig kernels at
least don't disable x2apic because of a lack of IRQ_REMAP support.
Patch 3 is a non-functional change renaming x2apic_available to
x2apic_without_ir_available in struct x86_hyper_init, to better convey
the semantic.
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
Shashank Balaji (3):
x86/x2apic: disable x2apic on resume if the kernel expects so
x86/defconfig: add CONFIG_IRQ_REMAP
x86/virt: rename x2apic_available to x2apic_without_ir_available
arch/x86/configs/x86_64_defconfig | 1 +
arch/x86/include/asm/x86_init.h | 4 ++--
arch/x86/kernel/apic/apic.c | 10 ++++++++--
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 ++--
11 files changed, 25 insertions(+), 18 deletions(-)
---
base-commit: 18f7fcd5e69a04df57b563360b88be72471d6b62
change-id: 20260201-x2apic-fix-85c8c1b5cb90
Best regards,
--
Shashank Balaji <shashank.mahadasyam@sony.com>
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-02 9:51 [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram Shashank Balaji
@ 2026-02-02 9:51 ` Shashank Balaji
2026-02-02 15:02 ` kernel test robot
` (2 more replies)
2026-02-02 9:51 ` [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP Shashank Balaji
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
2 siblings, 3 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-02 9:51 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird, stable
In lapic_resume, ensure x2apic is actually disabled when the kernel expects it
to be disabled, i.e. when x2apic_mode = 0.
x2apic_mode is set to 0 and x2apic is disabled on boot if the kernel doesn't
support irq remapping or for other reasons. On resume from s2ram
(/sys/power/mem_sleep = deep), firmware can re-enable x2apic, but the kernel
continues using the xapic interface because it didn't check to see if someone
enabled x2apic behind its back, which causes hangs. This situation happens on
defconfig + bare metal + s2ram, on which this fix has been tested.
Fixes: 6e1cb38a2aef ("x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping")
Cc: stable@vger.kernel.org
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/kernel/apic/apic.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index d93f87f29d03..cc64d61f82cf 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
if (x2apic_mode) {
__x2apic_enable();
} else {
+ /*
+ * x2apic may have been re-enabled by the
+ * firmware on resuming from s2ram
+ */
+ __x2apic_disable();
+
/*
* Make sure the APICBASE points to the right address
*
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP
2026-02-02 9:51 [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram Shashank Balaji
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
@ 2026-02-02 9:51 ` Shashank Balaji
2026-02-02 11:35 ` Andrew Cooper
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
2 siblings, 1 reply; 22+ messages in thread
From: Shashank Balaji @ 2026-02-02 9:51 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird
Interrupt remapping is an architectural dependency of x2apic, which is already
enabled in the defconfig. Enable CONFIG_IRQ_REMAP so that a defconfig kernel on
bare metal actually uses x2apic.
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/configs/x86_64_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 7d7310cdf8b0..269f7d808be4 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -230,6 +230,7 @@ CONFIG_EEEPC_LAPTOP=y
CONFIG_AMD_IOMMU=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
+CONFIG_IRQ_REMAP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available
2026-02-02 9:51 [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram Shashank Balaji
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
2026-02-02 9:51 ` [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP Shashank Balaji
@ 2026-02-02 9:51 ` Shashank Balaji
2026-02-06 0:10 ` Sohil Mehta
2026-02-13 7:39 ` Shashank Balaji
2 siblings, 2 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-02 9:51 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird
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.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP
2026-02-02 9:51 ` [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP Shashank Balaji
@ 2026-02-02 11:35 ` Andrew Cooper
2026-02-02 11:54 ` Jan Kiszka
0 siblings, 1 reply; 22+ messages in thread
From: Andrew Cooper @ 2026-02-02 11:35 UTC (permalink / raw)
To: Shashank Balaji, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Ajay Kaher,
Alexey Makhalov, Broadcom internal kernel review list, Jan Kiszka,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Andrew Cooper, Ingo Molnar, linux-kernel, linux-hyperv,
virtualization, jailhouse-dev, kvm, xen-devel, Rahul Bukte,
Daniel Palmer, Tim Bird
On 02/02/2026 9:51 am, Shashank Balaji wrote:
> Interrupt remapping is an architectural dependency of x2apic, which is already
> enabled in the defconfig.
There is no such dependency. VMs for example commonly have x2APIC and
no IOMMU, and even native system with fewer than 254 CPUs does not need
interrupt remapping for IO-APIC interrupts to function correctly.
For native systems with 255 or more CPUs you do want Interrupt Remapping
so enabling it in defconfig is a good move, but the justification needs
correcting.
~Andrew
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP
2026-02-02 11:35 ` Andrew Cooper
@ 2026-02-02 11:54 ` Jan Kiszka
2026-02-02 12:12 ` Andrew Cooper
0 siblings, 1 reply; 22+ messages in thread
From: Jan Kiszka @ 2026-02-02 11:54 UTC (permalink / raw)
To: Andrew Cooper, Shashank Balaji, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Suresh Siddha,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Daniel Palmer,
Tim Bird
On 02.02.26 12:35, Andrew Cooper wrote:
> On 02/02/2026 9:51 am, Shashank Balaji wrote:
>> Interrupt remapping is an architectural dependency of x2apic, which is already
>> enabled in the defconfig.
>
> There is no such dependency. VMs for example commonly have x2APIC and
> no IOMMU, and even native system with fewer than 254 CPUs does not need
> interrupt remapping for IO-APIC interrupts to function correctly.
>
It is theoretically possible with less than 254 CPUs, and that is why
virtualization uses it, but the Intel SDM clearly states:
"Routing of device interrupts to local APIC units operating in x2APIC
mode requires use of the interrupt-remapping architecture specified in
the Intel® Virtualization Technology for Directed I/O (Revision 1.3
and/or later versions)."
IIRC, ignoring this would move us into undefined behaviour space that
may work on some system and did not on others.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP
2026-02-02 11:54 ` Jan Kiszka
@ 2026-02-02 12:12 ` Andrew Cooper
2026-02-02 13:50 ` Jan Kiszka
0 siblings, 1 reply; 22+ messages in thread
From: Andrew Cooper @ 2026-02-02 12:12 UTC (permalink / raw)
To: Jan Kiszka, Shashank Balaji, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Suresh Siddha,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Andrew Cooper, Ingo Molnar, linux-kernel, linux-hyperv,
virtualization, jailhouse-dev, kvm, xen-devel, Rahul Bukte,
Daniel Palmer, Tim Bird
On 02/02/2026 11:54 am, Jan Kiszka wrote:
> On 02.02.26 12:35, Andrew Cooper wrote:
>> On 02/02/2026 9:51 am, Shashank Balaji wrote:
>>> Interrupt remapping is an architectural dependency of x2apic, which is already
>>> enabled in the defconfig.
>> There is no such dependency. VMs for example commonly have x2APIC and
>> no IOMMU, and even native system with fewer than 254 CPUs does not need
>> interrupt remapping for IO-APIC interrupts to function correctly.
>>
> It is theoretically possible with less than 254 CPUs, and that is why
> virtualization uses it, but the Intel SDM clearly states:
>
> "Routing of device interrupts to local APIC units operating in x2APIC
> mode requires use of the interrupt-remapping architecture specified in
> the Intel® Virtualization Technology for Directed I/O (Revision 1.3
> and/or later versions)."
This statement is misleading and has been argued over before. It's
missing the key word "all".
What IR gets you in this case is the ability to target CPU 255 and higher.
The OS-side access mechanism (xAPIC MMIO vs x2APIC MSRs) has no baring
on how external interrupts are handled in the fabric.
There are plenty of good reasons to have Interrupt Remapping enabled
when available, but it is not a hard requirement architecturally.
~Andrew
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP
2026-02-02 12:12 ` Andrew Cooper
@ 2026-02-02 13:50 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2026-02-02 13:50 UTC (permalink / raw)
To: Andrew Cooper, Shashank Balaji, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Suresh Siddha,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Daniel Palmer,
Tim Bird
On 02.02.26 13:12, Andrew Cooper wrote:
> On 02/02/2026 11:54 am, Jan Kiszka wrote:
>> On 02.02.26 12:35, Andrew Cooper wrote:
>>> On 02/02/2026 9:51 am, Shashank Balaji wrote:
>>>> Interrupt remapping is an architectural dependency of x2apic, which is already
>>>> enabled in the defconfig.
>>> There is no such dependency. VMs for example commonly have x2APIC and
>>> no IOMMU, and even native system with fewer than 254 CPUs does not need
>>> interrupt remapping for IO-APIC interrupts to function correctly.
>>>
>> It is theoretically possible with less than 254 CPUs, and that is why
>> virtualization uses it, but the Intel SDM clearly states:
>>
>> "Routing of device interrupts to local APIC units operating in x2APIC
>> mode requires use of the interrupt-remapping architecture specified in
>> the Intel® Virtualization Technology for Directed I/O (Revision 1.3
>> and/or later versions)."
>
> This statement is misleading and has been argued over before. It's
> missing the key word "all".
>
> What IR gets you in this case is the ability to target CPU 255 and higher.
>
> The OS-side access mechanism (xAPIC MMIO vs x2APIC MSRs) has no baring
> on how external interrupts are handled in the fabric.
>
> There are plenty of good reasons to have Interrupt Remapping enabled
> when available, but it is not a hard requirement architecturally.
>
If that is true, then this patch is the wrong one to blame because it
only reacts on existing kernel logic and repeats the arguments that are
in the code and even provided to kernel users. If you have hard proof
that the existing code is wrong (some confirmation from Intel folks
would be "nice" I guess), then propose a patch to change that logic.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
@ 2026-02-02 15:02 ` kernel test robot
2026-02-02 22:31 ` kernel test robot
2026-02-03 21:08 ` Sohil Mehta
2 siblings, 0 replies; 22+ messages in thread
From: kernel test robot @ 2026-02-02 15:02 UTC (permalink / raw)
To: Shashank Balaji, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Ajay Kaher,
Alexey Makhalov, Broadcom internal kernel review list, Jan Kiszka,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: oe-kbuild-all, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird
Hi Shashank,
kernel test robot noticed the following build errors:
[auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
base: 18f7fcd5e69a04df57b563360b88be72471d6b62
patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
config: x86_64-buildonly-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260202/202602022242.iSdFHMDI-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260202/202602022242.iSdFHMDI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602022242.iSdFHMDI-lkp@intel.com/
All errors (new ones prefixed by >>):
arch/x86/kernel/apic/apic.c: In function 'lapic_resume':
>> arch/x86/kernel/apic/apic.c:2463:17: error: implicit declaration of function '__x2apic_disable'; did you mean '__x2apic_enable'? [-Wimplicit-function-declaration]
2463 | __x2apic_disable();
| ^~~~~~~~~~~~~~~~
| __x2apic_enable
vim +2463 arch/x86/kernel/apic/apic.c
2435
2436 static void lapic_resume(void *data)
2437 {
2438 unsigned int l, h;
2439 unsigned long flags;
2440 int maxlvt;
2441
2442 if (!apic_pm_state.active)
2443 return;
2444
2445 local_irq_save(flags);
2446
2447 /*
2448 * IO-APIC and PIC have their own resume routines.
2449 * We just mask them here to make sure the interrupt
2450 * subsystem is completely quiet while we enable x2apic
2451 * and interrupt-remapping.
2452 */
2453 mask_ioapic_entries();
2454 legacy_pic->mask_all();
2455
2456 if (x2apic_mode) {
2457 __x2apic_enable();
2458 } else {
2459 /*
2460 * x2apic may have been re-enabled by the
2461 * firmware on resuming from s2ram
2462 */
> 2463 __x2apic_disable();
2464
2465 /*
2466 * Make sure the APICBASE points to the right address
2467 *
2468 * FIXME! This will be wrong if we ever support suspend on
2469 * SMP! We'll need to do this as part of the CPU restore!
2470 */
2471 if (boot_cpu_data.x86 >= 6) {
2472 rdmsr(MSR_IA32_APICBASE, l, h);
2473 l &= ~MSR_IA32_APICBASE_BASE;
2474 l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
2475 wrmsr(MSR_IA32_APICBASE, l, h);
2476 }
2477 }
2478
2479 maxlvt = lapic_get_maxlvt();
2480 apic_write(APIC_LVTERR, ERROR_APIC_VECTOR | APIC_LVT_MASKED);
2481 apic_write(APIC_ID, apic_pm_state.apic_id);
2482 apic_write(APIC_DFR, apic_pm_state.apic_dfr);
2483 apic_write(APIC_LDR, apic_pm_state.apic_ldr);
2484 apic_write(APIC_TASKPRI, apic_pm_state.apic_taskpri);
2485 apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
2486 apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
2487 apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
2488 #ifdef CONFIG_X86_THERMAL_VECTOR
2489 if (maxlvt >= 5)
2490 apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
2491 #endif
2492 #ifdef CONFIG_X86_MCE_INTEL
2493 if (maxlvt >= 6)
2494 apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
2495 #endif
2496 if (maxlvt >= 4)
2497 apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
2498 apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
2499 apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
2500 apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
2501 apic_write(APIC_ESR, 0);
2502 apic_read(APIC_ESR);
2503 apic_write(APIC_LVTERR, apic_pm_state.apic_lvterr);
2504 apic_write(APIC_ESR, 0);
2505 apic_read(APIC_ESR);
2506
2507 irq_remapping_reenable(x2apic_mode);
2508
2509 local_irq_restore(flags);
2510 }
2511
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
2026-02-02 15:02 ` kernel test robot
@ 2026-02-02 22:31 ` kernel test robot
2026-02-03 0:24 ` Shashank Balaji
2026-02-03 21:08 ` Sohil Mehta
2 siblings, 1 reply; 22+ messages in thread
From: kernel test robot @ 2026-02-02 22:31 UTC (permalink / raw)
To: Shashank Balaji, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Ajay Kaher,
Alexey Makhalov, Broadcom internal kernel review list, Jan Kiszka,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: llvm, oe-kbuild-all, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Shashank Balaji,
Daniel Palmer, Tim Bird
Hi Shashank,
kernel test robot noticed the following build errors:
[auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
base: 18f7fcd5e69a04df57b563360b88be72471d6b62
patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
config: i386-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602030600.jFhsJyEC-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/kernel/apic/apic.c:2463:3: error: call to undeclared function '__x2apic_disable'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
2463 | __x2apic_disable();
| ^
arch/x86/kernel/apic/apic.c:2463:3: note: did you mean '__x2apic_enable'?
arch/x86/kernel/apic/apic.c:1896:20: note: '__x2apic_enable' declared here
1896 | static inline void __x2apic_enable(void) { }
| ^
1 error generated.
vim +/__x2apic_disable +2463 arch/x86/kernel/apic/apic.c
2435
2436 static void lapic_resume(void *data)
2437 {
2438 unsigned int l, h;
2439 unsigned long flags;
2440 int maxlvt;
2441
2442 if (!apic_pm_state.active)
2443 return;
2444
2445 local_irq_save(flags);
2446
2447 /*
2448 * IO-APIC and PIC have their own resume routines.
2449 * We just mask them here to make sure the interrupt
2450 * subsystem is completely quiet while we enable x2apic
2451 * and interrupt-remapping.
2452 */
2453 mask_ioapic_entries();
2454 legacy_pic->mask_all();
2455
2456 if (x2apic_mode) {
2457 __x2apic_enable();
2458 } else {
2459 /*
2460 * x2apic may have been re-enabled by the
2461 * firmware on resuming from s2ram
2462 */
> 2463 __x2apic_disable();
2464
2465 /*
2466 * Make sure the APICBASE points to the right address
2467 *
2468 * FIXME! This will be wrong if we ever support suspend on
2469 * SMP! We'll need to do this as part of the CPU restore!
2470 */
2471 if (boot_cpu_data.x86 >= 6) {
2472 rdmsr(MSR_IA32_APICBASE, l, h);
2473 l &= ~MSR_IA32_APICBASE_BASE;
2474 l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
2475 wrmsr(MSR_IA32_APICBASE, l, h);
2476 }
2477 }
2478
2479 maxlvt = lapic_get_maxlvt();
2480 apic_write(APIC_LVTERR, ERROR_APIC_VECTOR | APIC_LVT_MASKED);
2481 apic_write(APIC_ID, apic_pm_state.apic_id);
2482 apic_write(APIC_DFR, apic_pm_state.apic_dfr);
2483 apic_write(APIC_LDR, apic_pm_state.apic_ldr);
2484 apic_write(APIC_TASKPRI, apic_pm_state.apic_taskpri);
2485 apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
2486 apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
2487 apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
2488 #ifdef CONFIG_X86_THERMAL_VECTOR
2489 if (maxlvt >= 5)
2490 apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
2491 #endif
2492 #ifdef CONFIG_X86_MCE_INTEL
2493 if (maxlvt >= 6)
2494 apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
2495 #endif
2496 if (maxlvt >= 4)
2497 apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
2498 apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
2499 apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
2500 apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
2501 apic_write(APIC_ESR, 0);
2502 apic_read(APIC_ESR);
2503 apic_write(APIC_LVTERR, apic_pm_state.apic_lvterr);
2504 apic_write(APIC_ESR, 0);
2505 apic_read(APIC_ESR);
2506
2507 irq_remapping_reenable(x2apic_mode);
2508
2509 local_irq_restore(flags);
2510 }
2511
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-02 22:31 ` kernel test robot
@ 2026-02-03 0:24 ` Shashank Balaji
0 siblings, 0 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-03 0:24 UTC (permalink / raw)
To: kernel test robot
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, llvm,
oe-kbuild-all, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Daniel Palmer,
Tim Bird
On Tue, Feb 03, 2026 at 06:31:40AM +0800, kernel test robot wrote:
> Hi Shashank,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 18f7fcd5e69a04df57b563360b88be72471d6b62]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Shashank-Balaji/x86-x2apic-disable-x2apic-on-resume-if-the-kernel-expects-so/20260202-181147
> base: 18f7fcd5e69a04df57b563360b88be72471d6b62
> patch link: https://lore.kernel.org/r/20260202-x2apic-fix-v1-1-71c8f488a88b%40sony.com
> patch subject: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
> config: i386-randconfig-001-20260202 (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260203/202602030600.jFhsJyEC-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202602030600.jFhsJyEC-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> arch/x86/kernel/apic/apic.c:2463:3: error: call to undeclared function '__x2apic_disable'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 2463 | __x2apic_disable();
> | ^
> arch/x86/kernel/apic/apic.c:2463:3: note: did you mean '__x2apic_enable'?
> arch/x86/kernel/apic/apic.c:1896:20: note: '__x2apic_enable' declared here
> 1896 | static inline void __x2apic_enable(void) { }
> | ^
> 1 error generated.
This happens when CONFIG_X86_X2APIC is disabled. This patch fixes it,
which I'll include in v2:
diff --git i/arch/x86/kernel/apic/apic.c w/arch/x86/kernel/apic/apic.c
index 8820b631f8a2..06cce23b89c1 100644
--- i/arch/x86/kernel/apic/apic.c
+++ w/arch/x86/kernel/apic/apic.c
@@ -1894,6 +1894,7 @@ void __init check_x2apic(void)
static inline void try_to_enable_x2apic(int remap_mode) { }
static inline void __x2apic_enable(void) { }
+static inline void __x2apic_disable(void) {}
#endif /* !CONFIG_X86_X2APIC */
void __init enable_IR_x2apic(void)
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
2026-02-02 15:02 ` kernel test robot
2026-02-02 22:31 ` kernel test robot
@ 2026-02-03 21:08 ` Sohil Mehta
2026-02-04 9:17 ` Shashank Balaji
2 siblings, 1 reply; 22+ messages in thread
From: Sohil Mehta @ 2026-02-03 21:08 UTC (permalink / raw)
To: Shashank Balaji, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Ajay Kaher,
Alexey Makhalov, Broadcom internal kernel review list, Jan Kiszka,
Paolo Bonzini, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Daniel Palmer,
Tim Bird, stable
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index d93f87f29d03..cc64d61f82cf 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
> if (x2apic_mode) {
> __x2apic_enable();
> } else {
> + /*
> + * x2apic may have been re-enabled by the
> + * firmware on resuming from s2ram
> + */
> + __x2apic_disable();
> +
We should likely only disable x2apic on platforms that support it and
need the disabling. How about?
...
} else {
/*
*
*/
if (x2apic_enabled())
__x2apic_disable();
I considered if an error message should be printed along with this. But,
I am not sure if it can really be called a firmware issue. It's probably
just that newer CPUs might have started defaulting to x2apic on.
Can you specify what platform you are encountering this?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-03 21:08 ` Sohil Mehta
@ 2026-02-04 9:17 ` Shashank Balaji
2026-02-04 18:53 ` Sohil Mehta
0 siblings, 1 reply; 22+ messages in thread
From: Shashank Balaji @ 2026-02-04 9:17 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
Hi Sohil,
On Tue, Feb 03, 2026 at 01:08:39PM -0800, Sohil Mehta wrote:
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index d93f87f29d03..cc64d61f82cf 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
> > if (x2apic_mode) {
> > __x2apic_enable();
> > } else {
> > + /*
> > + * x2apic may have been re-enabled by the
> > + * firmware on resuming from s2ram
> > + */
> > + __x2apic_disable();
> > +
>
> We should likely only disable x2apic on platforms that support it and
> need the disabling. How about?
>
> ...
> } else {
> /*
> *
> */
> if (x2apic_enabled())
> __x2apic_disable();
__x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC)
and x2apic is already enabled. x2apic_enabled also does the same checks,
the only difference being, it uses rdmsrq_safe instead of just rdmsrq,
which is what __x2apic_disable uses. The safe version is because of
Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in
__x2apic_disable should be changed to rdmsrq_safe.
> I considered if an error message should be printed along with this. But,
> I am not sure if it can really be called a firmware issue. It's probably
> just that newer CPUs might have started defaulting to x2apic on.
>
> Can you specify what platform you are encountering this?
I'm not sure it's the CPU defaulting to x2apic on. As per Section
12.12.5.1 of the Intel SDM:
On coming out of reset, the local APIC unit is enabled and is in
the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0.
So, the CPU should be turning on in xapic mode. In fact, when x2apic is
disabled in the firmware, this problem doesn't happen.
Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
firmware during resume. Disabling\n"?
[1] https://lore.kernel.org/all/20150116095927.GA18880@pd.tnic/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-04 9:17 ` Shashank Balaji
@ 2026-02-04 18:53 ` Sohil Mehta
2026-02-05 6:07 ` Shashank Balaji
0 siblings, 1 reply; 22+ messages in thread
From: Sohil Mehta @ 2026-02-04 18:53 UTC (permalink / raw)
To: Shashank Balaji
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On 2/4/2026 1:17 AM, Shashank Balaji wrote:
> __x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC)
> and x2apic is already enabled.
I meant the X86_FEATURE_X2APIC and not X86_FEATURE_APIC. But, thinking
about it more, checking that the CPU is really in X2APIC mode by reading
the MSR is good enough.
> x2apic_enabled also does the same checks,
> the only difference being, it uses rdmsrq_safe instead of just rdmsrq,
> which is what __x2apic_disable uses. The safe version is because of
> Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in
> __x2apic_disable should be changed to rdmsrq_safe.
I don't know if there is a strong justification for changing to
rdmsrq_safe() over here. Also, that would be beyond the scope of this
patch. In general, it's better to avoid such changes unless an actual
issue pops up.
>
>> I considered if an error message should be printed along with this. But,
>> I am not sure if it can really be called a firmware issue. It's probably
>> just that newer CPUs might have started defaulting to x2apic on.
>>
>> Can you specify what platform you are encountering this?
>
>
> I'm not sure it's the CPU defaulting to x2apic on. As per Section
> 12.12.5.1 of the Intel SDM:
>
> On coming out of reset, the local APIC unit is enabled and is in
> the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0.
>
> So, the CPU should be turning on in xapic mode. In fact, when x2apic is
> disabled in the firmware, this problem doesn't happen.
>
It's a bit odd then that the firmware chooses to enable x2apic without
the OS requesting it.
Linux maintains a concept of X2APIC_ON_LOCKED in x2apic_state which is
based on the hardware preference to keep the apic in X2APIC mode.
When you have x2apic enabled in firmware, but the system is in XAPIC
mode, can you read the values in MSR_IA32_ARCH_CAPABILITIES and
MSR_IA32_XAPIC_DISABLE_STATUS?
XAPIC shouldn't be disabled because you are running in that mode. But,
it would be good to confirm.
> Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
> firmware during resume. Disabling\n"?
I mainly want to make sure the firmware is really at fault before we add
such a print. But it seems likely now that the firmware messed up.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-04 18:53 ` Sohil Mehta
@ 2026-02-05 6:07 ` Shashank Balaji
2026-02-05 23:18 ` Sohil Mehta
0 siblings, 1 reply; 22+ messages in thread
From: Shashank Balaji @ 2026-02-05 6:07 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
> On 2/4/2026 1:17 AM, Shashank Balaji wrote:
>
> > __x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC)
> > and x2apic is already enabled.
>
> I meant the X86_FEATURE_X2APIC and not X86_FEATURE_APIC.
My bad, I got that wrong. __x2apic_disable checks for X86_FEATURE_APIC,
while x2apic_enabled checks for X86_FEATURE_X2APIC.
> But, thinking about it more, checking that the CPU is really in X2APIC mode
> by reading the MSR is good enough.
But yes, I agree.
> > x2apic_enabled also does the same checks,
> > the only difference being, it uses rdmsrq_safe instead of just rdmsrq,
> > which is what __x2apic_disable uses. The safe version is because of
> > Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in
> > __x2apic_disable should be changed to rdmsrq_safe.
>
> I don't know if there is a strong justification for changing to
> rdmsrq_safe() over here. Also, that would be beyond the scope of this
> patch. In general, it's better to avoid such changes unless an actual
> issue pops up.
Makes sense.
> >> I considered if an error message should be printed along with this. But,
> >> I am not sure if it can really be called a firmware issue. It's probably
> >> just that newer CPUs might have started defaulting to x2apic on.
> >>
> >> Can you specify what platform you are encountering this?
> >
> >
> > I'm not sure it's the CPU defaulting to x2apic on. As per Section
> > 12.12.5.1 of the Intel SDM:
> >
> > On coming out of reset, the local APIC unit is enabled and is in
> > the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0.
> >
> > So, the CPU should be turning on in xapic mode. In fact, when x2apic is
> > disabled in the firmware, this problem doesn't happen.
> >
>
> It's a bit odd then that the firmware chooses to enable x2apic without
> the OS requesting it.
Well, the firmware has a setting saying "Enable x2apic", which was
enabled. So it did what the setting says
> Linux maintains a concept of X2APIC_ON_LOCKED in x2apic_state which is
> based on the hardware preference to keep the apic in X2APIC mode.
>
> When you have x2apic enabled in firmware, but the system is in XAPIC
> mode, can you read the values in MSR_IA32_ARCH_CAPABILITIES and
> MSR_IA32_XAPIC_DISABLE_STATUS?
>
> XAPIC shouldn't be disabled because you are running in that mode. But,
> it would be good to confirm.
With x2apic enabled by the firmware, and after kernel switches to xapic
(because no interrupt remapping support), bit 21 (XAPIC_DISABLE_STATUS)
of MSR_IA32_ARCH_CAPABILITIES is 0, and MSR_IA32_XAPIC_DISABLE_STATUS
MSR is not available.
> > Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
> > firmware during resume. Disabling\n"?
>
> I mainly want to make sure the firmware is really at fault before we add
> such a print. But it seems likely now that the firmware messed up.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-05 6:07 ` Shashank Balaji
@ 2026-02-05 23:18 ` Sohil Mehta
2026-02-06 3:44 ` Shashank Balaji
2026-02-06 8:57 ` Shashank Balaji
0 siblings, 2 replies; 22+ messages in thread
From: Sohil Mehta @ 2026-02-05 23:18 UTC (permalink / raw)
To: Shashank Balaji
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On 2/4/2026 10:07 PM, Shashank Balaji wrote:
> On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>> It's a bit odd then that the firmware chooses to enable x2apic without
>> the OS requesting it.
>
> Well, the firmware has a setting saying "Enable x2apic", which was
> enabled. So it did what the setting says
>
The expectation would be that firmware would restore to the same state
before lapic_suspend().
>
>>> Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
>>> firmware during resume. Disabling\n"?
>>
>> I mainly want to make sure the firmware is really at fault before we add
>> such a print. But it seems likely now that the firmware messed up.
Maybe a warning would be useful to encourage firmware to fix this going
forward. I don't have a strong preference on the wording, but how about?
pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
resume.\n");
A few nits:
For the code comments, you can use more of the line width. Generally, 72
(perhaps even 80) chars is okay for comments dependent on the code in
the vicinity.
The tip tree has slightly unique preferences, such as capitalizing the
first word of the patch title.
Please refer:
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
@ 2026-02-06 0:10 ` Sohil Mehta
2026-02-06 9:23 ` Shashank Balaji
2026-02-13 7:39 ` Shashank Balaji
1 sibling, 1 reply; 22+ messages in thread
From: Sohil Mehta @ 2026-02-06 0:10 UTC (permalink / raw)
To: Shashank Balaji, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird
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?
> 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?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-05 23:18 ` Sohil Mehta
@ 2026-02-06 3:44 ` Shashank Balaji
2026-02-06 8:57 ` Shashank Balaji
1 sibling, 0 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-06 3:44 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
> Maybe a warning would be useful to encourage firmware to fix this going
> forward. I don't have a strong preference on the wording, but how about?
>
> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
> resume.\n");
That works
> A few nits:
>
> For the code comments, you can use more of the line width. Generally, 72
> (perhaps even 80) chars is okay for comments dependent on the code in
> the vicinity.
>
> The tip tree has slightly unique preferences, such as capitalizing the
> first word of the patch title.
>
> Please refer:
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
Thanks! I noticed that I also didn't use '()' for function names in the
commit message. I'll fix all these and add the pr_warn_once in v2.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-05 23:18 ` Sohil Mehta
2026-02-06 3:44 ` Shashank Balaji
@ 2026-02-06 8:57 ` Shashank Balaji
2026-02-07 0:37 ` Sohil Mehta
1 sibling, 1 reply; 22+ messages in thread
From: Shashank Balaji @ 2026-02-06 8:57 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
> On 2/4/2026 10:07 PM, Shashank Balaji wrote:
> > On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>
> >> It's a bit odd then that the firmware chooses to enable x2apic without
> >> the OS requesting it.
> >
> > Well, the firmware has a setting saying "Enable x2apic", which was
> > enabled. So it did what the setting says
> >
>
> The expectation would be that firmware would restore to the same state
> before lapic_suspend().
I'm a bit out of my depth here, but I went looking around, and this is from the
latest ACPI spec (v6.6) [1]:
When executing from the power-on reset vector as a result of waking
from an S2 or S3 sleep state, the platform firmware performs only the
hardware initialization required to restore the system to either the
state the platform was in prior to the initial operating system boot,
or to the pre-sleep configuration state. In multiprocessor systems,
non-boot processors should be placed in the same state as prior to the
initial operating system boot.
(further ahead)
If this is an S2 or S3 wake, then the platform runtime firmware
restores minimum context of the system before jumping to the waking
vector. This includes:
CPU configuration. Platform runtime firmware restores the
pre-sleep configuration or initial boot configuration of each
CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts
must be disabled (for IA-32 processors, disabled by CLI
instruction).
(and other things)
I suppose, in my case, the firmware is restoring initial boot
configuration on S3 resume. And initial boot configuration of x2apic is
set from the firmware's UI "Enable x2apic".
> Maybe a warning would be useful to encourage firmware to fix this going
> forward. I don't have a strong preference on the wording, but how about?
>
> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
> resume.\n");
At least as per the spec, it's not something the firmware needs to fix,
and it's not unexpected re-enablement.
Am I missing something?
But it _is_ surprising that this bug went unnoticed for so long :)
[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available
2026-02-06 0:10 ` Sohil Mehta
@ 2026-02-06 9:23 ` Shashank Balaji
0 siblings, 0 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-06 9:23 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, linux-kernel,
linux-hyperv, virtualization, jailhouse-dev, kvm, xen-devel,
Rahul Bukte, Daniel Palmer, Tim Bird
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?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
2026-02-06 8:57 ` Shashank Balaji
@ 2026-02-07 0:37 ` Sohil Mehta
0 siblings, 0 replies; 22+ messages in thread
From: Sohil Mehta @ 2026-02-07 0:37 UTC (permalink / raw)
To: Shashank Balaji
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
On 2/6/2026 12:57 AM, Shashank Balaji wrote:
> On Thu, Feb 05, 2026 at 03:18:58PM -0800, Sohil Mehta wrote:
>> On 2/4/2026 10:07 PM, Shashank Balaji wrote:
>>> On Wed, Feb 04, 2026 at 10:53:28AM -0800, Sohil Mehta wrote:
>>
>>>> It's a bit odd then that the firmware chooses to enable x2apic without
>>>> the OS requesting it.
>>>
>>> Well, the firmware has a setting saying "Enable x2apic", which was
>>> enabled. So it did what the setting says
>>>
>>
I still think the firmware behavior is flawed. Some confusion
originates from the option "Enable x2apic". Based on just these two
words, the behavior seems highly ambiguous. I interpret it to mean "Make
the x2apic feature available to the kernel". Then it is up to the kernel
whether it decides to use it.
If the intention of the BIOS option is to automatically/always enable
x2apic then there is an architectural way to do it. It can set the bits
that track to x2apic_hw_locked(). But, doing it this way during resume
(behind OS's back) is unexpected.
>>
>> pr_warn_once("x2apic unexpectedly re-enabled by the firmware during
>> resume.\n");
>
> At least as per the spec, it's not something the firmware needs to fix,
> and it's not unexpected re-enablement.
>
> Am I missing something?
>
> But it _is_ surprising that this bug went unnoticed for so long :)
Maybe this BIOS option isn't typically found in a production firmware. I
think it would be preferable to have the pr_warn_once() but I won't push
super hard for it due to the unclear information.
Whatever you choose for v2, can you please briefly describe the
ambiguity in the commit message? It would help other reviewers provide
better insight and be handy if we ever need to come back to this.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
2026-02-06 0:10 ` Sohil Mehta
@ 2026-02-13 7:39 ` Shashank Balaji
1 sibling, 0 replies; 22+ messages in thread
From: Shashank Balaji @ 2026-02-13 7:39 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky
Cc: Ingo Molnar, linux-kernel, linux-hyperv, virtualization,
jailhouse-dev, kvm, xen-devel, Rahul Bukte, Daniel Palmer,
Tim Bird, Sohil Mehta
Hi x86 and virt folks,
I'd like some feedback on this patch. I realise that just updating the
name to x2apic_without_ir_available() with no indication in the code
suggesting that the hypervisor implementations may not be answering the
question "is x2apic availalble without IR?" is bad.
I suppose the options are:
1. Check seven hypervisor's x2apic_available() implementation to see if
the "x2apic_without_ir_available" semantic matches, and then do the
renaming
Problem is, I don't know enough about the hypervisors to check
the implementations. Some help from the virt folks would be
great!
2. Add TODOs on the hypervisor implementations, hoping they'll be
audited in the future
There's a chance the TODOs will just sit there rotting. It's
ugly, even I don't like it
So how do we proceed?
On Mon, Feb 02, 2026 at 06:51:04PM +0900, 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.
>
> 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.0
>
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2026-02-13 7:40 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-02 9:51 [PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram Shashank Balaji
2026-02-02 9:51 ` [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so Shashank Balaji
2026-02-02 15:02 ` kernel test robot
2026-02-02 22:31 ` kernel test robot
2026-02-03 0:24 ` Shashank Balaji
2026-02-03 21:08 ` Sohil Mehta
2026-02-04 9:17 ` Shashank Balaji
2026-02-04 18:53 ` Sohil Mehta
2026-02-05 6:07 ` Shashank Balaji
2026-02-05 23:18 ` Sohil Mehta
2026-02-06 3:44 ` Shashank Balaji
2026-02-06 8:57 ` Shashank Balaji
2026-02-07 0:37 ` Sohil Mehta
2026-02-02 9:51 ` [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP Shashank Balaji
2026-02-02 11:35 ` Andrew Cooper
2026-02-02 11:54 ` Jan Kiszka
2026-02-02 12:12 ` Andrew Cooper
2026-02-02 13:50 ` Jan Kiszka
2026-02-02 9:51 ` [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available Shashank Balaji
2026-02-06 0:10 ` Sohil Mehta
2026-02-06 9:23 ` Shashank Balaji
2026-02-13 7:39 ` Shashank Balaji
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox