[PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram

[PATCH 0/3] x86/x2apic: Fix hang-up of defconfig kernel on resume from s2ram

[Shashank Balaji]

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>

[PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[kernel test robot]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[kernel test robot]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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)

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Sohil Mehta]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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/

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Sohil Mehta]

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.

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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.

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Sohil Mehta]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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.

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Shashank Balaji]

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

Re: [PATCH 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so

[Sohil Mehta]

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.

[PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP

[Shashank Balaji]

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

Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP

[Andrew Cooper]

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

Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP

[Jan Kiszka]

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

Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP

[Andrew Cooper]

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

Re: [PATCH 2/3] x86/defconfig: add CONFIG_IRQ_REMAP

[Jan Kiszka]

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

[PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available

[Shashank Balaji]

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

Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available

[Sohil Mehta]

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?

Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available

[Shashank Balaji]

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?

Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available

[Shashank Balaji]

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
>