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

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

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

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

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