As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
present, enable CONFIG_X86_X2APIC by default as it gives performance
and functionality benefits. Additionally, if the BIOS has already
switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
kernel will panic in arch/x86/kernel/apic/apic.c .
Also improve the help text, which was confusing and really did not
describe what the feature is about.
Help text references and discussion:
Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic".
"It allows faster access to the local APIC"
[2], chapter 2.1, page 15:
"More efficient MSR interface to access APIC registers."
"x2APIC was introduced in Intel CPUs around 2008":
I was unable to find specific information which Intel CPUs
support x2APIC. Wikipedia claims it was "introduced with the
Nehalem microarchitecture in November 2008", but I was not able
to confirm this independently. At least some Nehalem CPUs do not
support x2APIC [1].
The documentation [2] is dated June 2008. Linux kernel also
introduced x2APIC support in 2008, so the year seems to be
right.
"and in AMD EPYC CPUs in 2019":
[3], page 15:
"AMD introduced an x2APIC in our EPYC 7002 Series processors for
the first time."
"It is also frequently emulated in virtual machines, even when the host
CPU does not support it."
[1]
"If this configuration option is disabled, the kernel will not boot on
some platforms that have x2APIC enabled."
According to some BIOS documentation [4], the x2APIC may be
"disabled", "enabled", or "force enabled" on this system.
I think that "enabled" means "made available to the operating
system, but not already turned on" and "force enabled" means
"already switched to x2APIC mode when the OS boots". Only in the
latter mode a kernel without CONFIG_X86_X2APIC will panic in
validate_x2apic() in arch/x86/kernel/apic/apic.c .
QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the
"enabled" mode and the kernel does not panic.
[1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup"
https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html
[2] Intel® 64 Architecture x2APIC Specification,
( https://www.naic.edu/~phil/software/intel/318148.pdf )
[3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based
Servers Application Note,
https://developer.amd.com/wp-content/resources/56745_0.80.pdf
[4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant
Gen10, ProLiant Gen10 Plus Servers and HPE Synergy:
Enabling or disabling Processor x2APIC Support
https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html
Signed-off-by: Mateusz Jończyk <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: [email protected]
Cc: "H. Peter Anvin" <[email protected]>
Cc: Yinghai Lu <[email protected]>
Cc: Randy Dunlap <[email protected]>
---
v2: language fixes by Mr Randy Dunlap, change option name
---
arch/x86/Kconfig | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..28133b5d3f12 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
If in doubt, say Y.
config X86_X2APIC
- bool "Support x2apic"
+ bool "x2APIC interrupt controller architecture support"
depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
+ default y
help
- This enables x2apic support on CPUs that have this feature.
+ x2APIC is an interrupt controller architecture, a component of which
+ (the local APIC) is present in the CPU. It allows faster access to
+ the local APIC and supports a larger number of CPUs in the system
+ than the predecessors.
- This allows 32-bit apic IDs (so it can support very large systems),
- and accesses the local apic via MSRs not via mmio.
+ x2APIC was introduced in Intel CPUs around 2008 and in AMD EPYC CPUs
+ in 2019, but it can be disabled by the BIOS. It is also frequently
+ emulated in virtual machines, even when the host CPU does not support
+ it. Support in the CPU can be checked by executing
+ cat /proc/cpuinfo | grep x2apic
- If you don't know what to do here, say N.
+ If this configuration option is disabled, the kernel will not boot on
+ some platforms that have x2APIC enabled.
+
+ Say N if you know that your platform does not have x2APIC.
+
+ Otherwise, say Y.
config X86_MPPARSE
bool "Enable MPS table" if ACPI
--
2.25.1
On Sun, Sep 11, 2022 at 10:47:02AM +0200, Mateusz Jończyk wrote:
> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
> present, enable CONFIG_X86_X2APIC by default as it gives performance
> and functionality benefits.
Can we do that without any detriment to older systems which don't have
x2APIC?
It looks so from a quick look...
> Additionally, if the BIOS has already
> switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
> kernel will panic in arch/x86/kernel/apic/apic.c .
>
> Also improve the help text, which was confusing and really did not
> describe what the feature is about.
>
> Help text references and discussion:
So I'm not sure this discussion should be part of the commit message.
You can put it under the "---" line of the patch though.
>
> Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic".
>
> "It allows faster access to the local APIC"
> [2], chapter 2.1, page 15:
> "More efficient MSR interface to access APIC registers."
>
> "x2APIC was introduced in Intel CPUs around 2008":
> I was unable to find specific information which Intel CPUs
> support x2APIC. Wikipedia claims it was "introduced with the
> Nehalem microarchitecture in November 2008", but I was not able
> to confirm this independently. At least some Nehalem CPUs do not
> support x2APIC [1].
>
> The documentation [2] is dated June 2008. Linux kernel also
> introduced x2APIC support in 2008, so the year seems to be
> right.
>
> "and in AMD EPYC CPUs in 2019":
> [3], page 15:
> "AMD introduced an x2APIC in our EPYC 7002 Series processors for
> the first time."
>
> "It is also frequently emulated in virtual machines, even when the host
> CPU does not support it."
> [1]
>
> "If this configuration option is disabled, the kernel will not boot on
> some platforms that have x2APIC enabled."
> According to some BIOS documentation [4], the x2APIC may be
> "disabled", "enabled", or "force enabled" on this system.
> I think that "enabled" means "made available to the operating
> system, but not already turned on" and "force enabled" means
> "already switched to x2APIC mode when the OS boots". Only in the
> latter mode a kernel without CONFIG_X86_X2APIC will panic in
> validate_x2apic() in arch/x86/kernel/apic/apic.c .
>
> QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the
> "enabled" mode and the kernel does not panic.
>
> [1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup"
> https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html
>
> [2] Intel® 64 Architecture x2APIC Specification,
> ( https://www.naic.edu/~phil/software/intel/318148.pdf )
>
> [3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based
> Servers Application Note,
> https://developer.amd.com/wp-content/resources/56745_0.80.pdf
>
> [4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant
> Gen10, ProLiant Gen10 Plus Servers and HPE Synergy:
> Enabling or disabling Processor x2APIC Support
> https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html
>
> Signed-off-by: Mateusz Jończyk <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Dave Hansen <[email protected]>
> Cc: [email protected]
> Cc: "H. Peter Anvin" <[email protected]>
> Cc: Yinghai Lu <[email protected]>
> Cc: Randy Dunlap <[email protected]>
>
> ---
> v2: language fixes by Mr Randy Dunlap, change option name
> ---
> arch/x86/Kconfig | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f9920f1341c8..28133b5d3f12 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
> If in doubt, say Y.
>
> config X86_X2APIC
> - bool "Support x2apic"
> + bool "x2APIC interrupt controller architecture support"
s/architecture //g
and below too. Keep it simple pls.
> depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
> + default y
> help
> - This enables x2apic support on CPUs that have this feature.
> + x2APIC is an interrupt controller architecture, a component of which
> + (the local APIC) is present in the CPU. It allows faster access to
> + the local APIC and supports a larger number of CPUs in the system
> + than the predecessors.
>
> - This allows 32-bit apic IDs (so it can support very large systems),
> - and accesses the local apic via MSRs not via mmio.
> + x2APIC was introduced in Intel CPUs around 2008 and in AMD EPYC CPUs
> + in 2019, but it can be disabled by the BIOS. It is also frequently
> + emulated in virtual machines, even when the host CPU does not support
> + it. Support in the CPU can be checked by executing
> + cat /proc/cpuinfo | grep x2apic
or simply
$ grep x2apic /proc/cpuinfo
>
> - If you don't know what to do here, say N.
> + If this configuration option is disabled, the kernel will not boot on
> + some platforms that have x2APIC enabled.
> +
> + Say N if you know that your platform does not have x2APIC.
Does it matter?
If the platform doesn't support it, it'll fallback to APIC anyway.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
> present, enable CONFIG_X86_X2APIC by default as it gives performance
> and functionality benefits. Additionally, if the BIOS has already
> switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the
> kernel will panic in arch/x86/kernel/apic/apic.c .
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> @@ -440,15 +440,27 @@ config X86_FEATURE_NAMES
> If in doubt, say Y.
>
> config X86_X2APIC
> - bool "Support x2apic"
> + bool "x2APIC interrupt controller architecture support"
> depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
> HYPERVISOR_GUEST)
> + default y
Could this option be added to
arch/x86/configs/x86_64_defconfig
so defconfig builds don't crash on current platforms?
On 10/27/22 07:45, Elliott, Robert (Servers) wrote:
>> config X86_X2APIC
>> - bool "Support x2apic"
>> + bool "x2APIC interrupt controller architecture support"
>> depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
>> HYPERVISOR_GUEST)
>> + default y
> Could this option be added to
> arch/x86/configs/x86_64_defconfig
>
> so defconfig builds don't crash on current platforms?
Sounds reasonable. Care to send a patch?
> -----Original Message-----
> From: Dave Hansen <[email protected]>
> Sent: Thursday, October 27, 2022 10:08 AM
...
> Subject: Re: [PATCH v2 01/10] x86/Kconfig: enable X86_X2APIC by default
> and improve help text
>
> On 10/27/22 07:45, Elliott, Robert (Servers) wrote:
> >> config X86_X2APIC
> >> - bool "Support x2apic"
> >> + bool "x2APIC interrupt controller architecture support"
> >> depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP ||
> >> HYPERVISOR_GUEST)
> >> + default y
> > Could this option be added to
> > arch/x86/configs/x86_64_defconfig
> >
> > so defconfig builds don't crash on current platforms?
>
> Sounds reasonable. Care to send a patch?
How are the defconfig files supposed to keep up with valid
combinations of options?
arch/x86/Kconfig has this set of dependencies:
config X86_X2APIC
bool "Support x2apic"
depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
config X86_LOCAL_APIC
def_bool y
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
select IRQ_DOMAIN_HIERARCHY
select PCI_MSI_IRQ_DOMAIN if PCI_MSI
config X86_IO_APIC
def_bool y
depends on X86_LOCAL_APIC || X86_UP_IOAPIC
drivers/iommu/Kconfig has:
config IRQ_REMAP
bool "Support for Interrupt Remapping"
depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
select DMAR_TABLE
Despite its filename, arch/x86/configs/x86_64_defconfig does not even have:
CONFIG_X86_64=y
which enables many options. That was added by:
commit 622e3f28e50f ("x86: 64-bit defconfig remake")
Sun May 4 19:57:19 2008 +0400
but removed by:
commit 8b1bb90701f9a51f ("defconfig reduction")
Sat Aug 14 22:05:58 2010 +0200
It does have
CONFIG_SMP=y
which should imply X86_LOCAL_APIC, but that's missing too.
It does have
CONFIG_HYPERVISOR_GUEST=y
so doesn't need IRQ_REMAP to enable X86_X2APIC.
On 11/3/22 16:41, Elliott, Robert (Servers) wrote:
> How are the defconfig files supposed to keep up with valid
> combinations of options?
On some level, it doesn't matter as long as "make defconfig" and the
Kconfig rules result in something generally sane.
> Despite its filename, arch/x86/configs/x86_64_defconfig does not even have:
> CONFIG_X86_64=y
> which enables many options. That was added by:
> commit 622e3f28e50f ("x86: 64-bit defconfig remake")
> Sun May 4 19:57:19 2008 +0400
> but removed by:
> commit 8b1bb90701f9a51f ("defconfig reduction")
> Sat Aug 14 22:05:58 2010 +0200
>
> It does have
> CONFIG_SMP=y
>
> which should imply X86_LOCAL_APIC, but that's missing too.
>
> It does have
> CONFIG_HYPERVISOR_GUEST=y
> so doesn't need IRQ_REMAP to enable X86_X2APIC.
It sounds like folks generally want the defconfig files to have minimal
contents. CONFIG_X86_64 isn't in there because it's not _needed_.
So, if the attached patch results in:
$ rm .config
$ make defconfig
$ grep X86_X2APIC .config
CONFIG_X86_X2APIC=y
Is there really anything else we need? Kconfig seems to have figured
everything out just fine and without any complaints.
On Wed, Oct 26 2022 at 20:38, Borislav Petkov wrote:
> On Sun, Sep 11, 2022 at 10:47:02AM +0200, Mateusz Jończyk wrote:
>> As many current platforms (most modern Intel CPUs and QEMU) have x2APIC
>> present, enable CONFIG_X86_X2APIC by default as it gives performance
>> and functionality benefits.
>
> Can we do that without any detriment to older systems which don't have
> x2APIC?
Can we please adjust to reality and do:
X86_X2APIC
bool
default y if X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
There is zero reason for having a knob.
Thanks,
tglx
Hello Mat,
any chance you would incorporate feedback and respin the series or/and
at least X2APIC parts?
For recent HW it becoming really necessary to have this option enabled.
Thank you
David
--
David Heidelberg
W dniu 2.02.2024 o 15:08, David Heidelberg pisze:
> Hello Mat,
>
> any chance you would incorporate feedback and respin the series or/and at least X2APIC parts?
> For recent HW it becoming really necessary to have this option enabled.
>
> Thank you
> David
>
Hello,
OK, I'll rebase, update and send the X2APIC patch. Can't give you an ETA though.
I have mostly gave up kernel development, but you keep me motivated.
Greetings,
Mateusz
Sure, thank you a lot!
David
On 15/02/2024 22:10, Mateusz Jończyk wrote:
> W dniu 2.02.2024 o 15:08, David Heidelberg pisze:
>> Hello Mat,
>>
>> any chance you would incorporate feedback and respin the series or/and at least X2APIC parts?
>> For recent HW it becoming really necessary to have this option enabled.
>>
>> Thank you
>> David
>>
> Hello,
>
> OK, I'll rebase, update and send the X2APIC patch. Can't give you an ETA though.
>
> I have mostly gave up kernel development, but you keep me motivated.
>
> Greetings,
>
> Mateusz
>
--
David Heidelberg