[PATCH 0/3] x86: Make processor vendor selection available without EXPERT

[PATCH 0/3] x86: Make processor vendor selection available without EXPERT

[Vincent Mailhol]

Restricting a kernel build to a known CPU vendor currently requires
enabling EXPERT.

Make PROCESSOR_SELECT available without EXPERT. It remains disabled by
default, preserving support for all applicable CPU vendors in existing
configurations.

This allows someone to deselect the irrelevant CPU vendors when building
a kernel for a specific machine without having to navigate in the EXPERT
menu option. Doing that reduces the questions asked when doing a

  make oldconfig

during a kernel update.

This also simplifies kernel trimming when building for a given
machine. In comparison to an x86_64 defconfig, the final vmlinux.o
image size decreases by 0.35% for an Intel-only configuration and by
8.88% for an AMD-only one.

In addition to the above, several CPU-specific options lack proper
dependencies and remain available when support for their processor
vendor has been disabled.

The first two patches fix the missing CPU_SUP_* dependencies by
properly gating features that would otherwise be useless without that
specific CPU vendor support, namely:

  - Intel and Zhaoxin machine-check extensions
  - legacy AMD NUMA detection

The third and final patch is the main change and removes the EXPERT
dependency from PROCESSOR_SELECT.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Vincent Mailhol (3):
      x86/mce: Add CPU_SUP_* dependencies for Intel/Zhaoxin MCE features
      x86/numa: Add CPU_SUP_AMD dependency for legacy AMD NUMA
      x86/cpu: don't gate PROCESSOR_SELECT with EXPERT

 arch/x86/Kconfig     |  4 ++--
 arch/x86/Kconfig.cpu | 22 +++++-----------------
 2 files changed, 7 insertions(+), 19 deletions(-)
---
base-commit: 36aad21d50d1af3f6954bb0c988257a908202477
change-id: 20261030-processor_select_is_not_an_expert_feature-4f329d352ec3

Best regards,
--  
Vincent Mailhol <mailhol@kernel.org>

[PATCH 1/3] x86/mce: Add CPU_SUP_* dependencies for Intel/Zhaoxin MCE features

[Vincent Mailhol]

Intel-style MCE features are only used on Intel and Zhaoxin CPUs.
Gate X86_MCE_INTEL on CPU_SUP_INTEL || CPU_SUP_ZHAOXIN.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 58dce0b66179..e09ec15a689a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1159,7 +1159,7 @@ config X86_MCELOG_LEGACY
 config X86_MCE_INTEL
 	def_bool y
 	prompt "Intel MCE features"
-	depends on X86_MCE && X86_LOCAL_APIC
+	depends on X86_MCE && X86_LOCAL_APIC && (CPU_SUP_INTEL || CPU_SUP_ZHAOXIN)
 	help
 	  Additional support for intel specific MCE features such as
 	  the thermal monitor.

-- 
2.56.0

[PATCH 2/3] x86/numa: Add CPU_SUP_AMD dependency for legacy AMD NUMA

[Vincent Mailhol]

The legacy AMD NUMA probe reads topology from an Opteron northbridge.

It is only useful when AMD CPUs are supported, so gate it with
CPU_SUP_AMD.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e09ec15a689a..6ee0265b5483 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1524,7 +1524,7 @@ config NUMA
 config AMD_NUMA
 	def_bool y
 	prompt "Old style AMD Opteron NUMA detection"
-	depends on X86_64 && NUMA && PCI
+	depends on X86_64 && NUMA && PCI && CPU_SUP_AMD
 	help
 	  Enable AMD NUMA node topology detection.  You should say Y here if
 	  you have a multi processor AMD system. This uses an old method to

-- 
2.56.0

[PATCH 3/3] x86/cpu: don't gate PROCESSOR_SELECT with EXPERT

[Vincent Mailhol]

When doing a make oldconfig, the user might get asked questions about
processor vendors. When the goal is to build a kernel for a specific
machine, those questions are irrelevant.

PROCESSOR_SELECT is a nice candidate to configure the CPU vendors once
and for all, but that feature is gated by EXPERT. It is unclear why this
menu should be hidden from the normal users. In comparison with the
other EXPERT features, knowing your CPU vendor does not require advanced
knowledge. After all, most machines even have a sticker on them to
remind you what is "inside".

Remove the EXPERT dependency from PROCESSOR_SELECT. Make the option N by
default so that all x86 CPU types remain supported by default.

This preserves the current default but now makes it easy to opt out when
configuring for a specific machine.

Finally, rephrase the menu guidance to make the description clearer:

  - Change the PROCESSOR_SELECT entry text from "Supported processor
    vendors" to "Customize supported processor vendors" to better
    describe what the option does.

  - Add a paragraph to PROCESSOR_SELECT help text to clarify that N is a
    safe default.

  - For each of the CPU_SUP_* entries, remove the "If unsure, say N"
    sentence from the help text.

As a side benefit, this also allows users to more easily trim their
kernel without having to activate the EXPERT option or navigate many
submenus. This is illustrated in the measurements below done with gcc
15.3.0, which compare three builds: an x86_64 defconfig, that same
defconfig with only CONFIG_CPU_SUP_INTEL kept, then only
CONFIG_CPU_SUP_AMD kept and the other CONFIG_CPU_SUP_* deselected:

  $ size vmlinux_{defconfig,intel_only,amd_only}.o
     text      data       bss       dec       hex       filename
  29927107   4934948    752852   35614907   21f70bb   vmlinux_defconfig.o
  29819807   4919587    752340   35491734   21d8f96   vmlinux_intel_only.o
  27452359   4252858    748692   32453909   1ef3515   vmlinux_amd_only.o

This shows a 0.35% reduction on an intel-only configuration and an 8.88%
reduction for an amd-only one.

The big difference in the amd-only build size is mostly explained by the
fact that CONFIG_MITIGATION_CALL_DEPTH_TRACKING gets automatically
disabled when removing CONFIG_CPU_SUP_INTEL.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
 arch/x86/Kconfig.cpu | 22 +++++-----------------
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 6e7a366f0798..01eace1ea1f8 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -306,11 +306,15 @@ config X86_VMX_FEATURE_NAMES
 	depends on IA32_FEAT_CTL
 
 menuconfig PROCESSOR_SELECT
-	bool "Supported processor vendors" if EXPERT
+	default n
+	bool "Customize supported processor vendors"
 	help
 	  This lets you choose what x86 vendor support code your kernel
 	  will include.
 
+	  To compile a kernel that can run on all supported x86 CPU types,
+	  or if unsure, say N.
+
 config CPU_SUP_INTEL
 	default y
 	bool "Support Intel processors" if PROCESSOR_SELECT
@@ -322,8 +326,6 @@ config CPU_SUP_INTEL
 	  makes the kernel a tiny bit smaller. Disabling it on an Intel
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_CYRIX_32
 	default y
 	bool "Support Cyrix processors" if PROCESSOR_SELECT
@@ -336,8 +338,6 @@ config CPU_SUP_CYRIX_32
 	  makes the kernel a tiny bit smaller. Disabling it on a Cyrix
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_AMD
 	default y
 	bool "Support AMD processors" if PROCESSOR_SELECT
@@ -349,8 +349,6 @@ config CPU_SUP_AMD
 	  makes the kernel a tiny bit smaller. Disabling it on an AMD
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_HYGON
 	default y
 	bool "Support Hygon processors" if PROCESSOR_SELECT
@@ -363,8 +361,6 @@ config CPU_SUP_HYGON
 	  makes the kernel a tiny bit smaller. Disabling it on an Hygon
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_CENTAUR
 	default y
 	bool "Support Centaur processors" if PROCESSOR_SELECT
@@ -376,8 +372,6 @@ config CPU_SUP_CENTAUR
 	  makes the kernel a tiny bit smaller. Disabling it on a Centaur
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_TRANSMETA_32
 	default y
 	bool "Support Transmeta processors" if PROCESSOR_SELECT
@@ -390,8 +384,6 @@ config CPU_SUP_TRANSMETA_32
 	  makes the kernel a tiny bit smaller. Disabling it on a Transmeta
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_ZHAOXIN
 	default y
 	bool "Support Zhaoxin processors" if PROCESSOR_SELECT
@@ -403,8 +395,6 @@ config CPU_SUP_ZHAOXIN
 	  makes the kernel a tiny bit smaller. Disabling it on a Zhaoxin
 	  CPU might render the kernel unbootable.
 
-	  If unsure, say N.
-
 config CPU_SUP_VORTEX_32
 	default y
 	bool "Support Vortex processors" if PROCESSOR_SELECT
@@ -416,8 +406,6 @@ config CPU_SUP_VORTEX_32
 	  Vortex CPU. Disabling this option on other types of CPUs
 	  makes the kernel a tiny bit smaller.
 
-	  If unsure, say N.
-
 config BROADCAST_TLB_FLUSH
 	def_bool y
 	depends on CPU_SUP_AMD && 64BIT

-- 
2.56.0

Re: [PATCH 3/3] x86/cpu: don't gate PROCESSOR_SELECT with EXPERT

[Dave Hansen]

On 10/31/26 00:51, Vincent Mailhol wrote:
> Remove the EXPERT dependency from PROCESSOR_SELECT. Make the option N by
> default so that all x86 CPU types remain supported by default.

I actually kinda despise the vendor selection stuff in the first place.

It just causes problems. Like for protection keys. I diligently made it
Intel-only when it was merged. But AMD came along and ruined my party
when they added support for it. We had to go do more work later to make
it available on AMD.

It's also one of those things that inevitably hides build problems.

Hiding it all behind EXPERT seems very prudent to me. I'm not seeing
justification in this series to change that.

Re: [PATCH 0/3] x86: Make processor vendor selection available without EXPERT

[Borislav Petkov]

On Sat, Oct 31, 2026 at 08:51:48AM +0100, Vincent Mailhol wrote:
> Restricting a kernel build to a known CPU vendor currently requires
> enabling EXPERT.
> 
> Make PROCESSOR_SELECT available without EXPERT. It remains disabled by
> default, preserving support for all applicable CPU vendors in existing
> configurations.

What I am not seeing is git archeology about why it is behind EXPERT and
whether that reason is or is not valid anymore.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 3/3] x86/cpu: don't gate PROCESSOR_SELECT with EXPERT

[Vincent Mailhol]

On 31/10/2026 at 14:58, Dave Hansen wrote:
> On 10/31/26 00:51, Vincent Mailhol wrote:
>> Remove the EXPERT dependency from PROCESSOR_SELECT. Make the option N by
>> default so that all x86 CPU types remain supported by default.
> 
> I actually kinda despise the vendor selection stuff in the first place.
> 
> It just causes problems. Like for protection keys. I diligently made it
> Intel-only when it was merged. But AMD came along and ruined my party
> when they added support for it. We had to go do more work later to make
> it available on AMD.

I think I am still missing the connection between the protection-key
example and keeping PROCESSOR_SELECT behind EXPERT. When AMD added
protection-key support, the dependency needed updating regardless of
whether vendor selection was visible outside EXPERT.

I understand that setting the correct CPU_SUP_* dependencies can be
challenging, but those dependencies are the developer's
responsibility. I don't think EXPERT is intended to hide symbols
whose dependencies are difficult to implement correctly in Kconfig. My
understanding is that it hides questions which require advanced
knowledge from the user configuring the kernel.

> It's also one of those things that inevitably hides build problems.
> 
> Hiding it all behind EXPERT seems very prudent to me. I'm not seeing
> justification in this series to change that.

My justification is that the configuration process currently seems
backward. For example, an AMD-only build doesn't need
MITIGATION_CALL_DEPTH_TRACKING. Today, the user would need to navigate
the "Mitigations for CPU vulnerabilities" menu and understand that
option to disable it individually. It seems easier to ask which CPU
vendors need to be supported and let Kconfig exclude features specific
to the other vendors. The same reasoning applies to other symbols with
CPU_SUP_* dependencies.

Generally speaking, my opinion is that EXPERT should be applied to the
child symbols rather than their parents. The deeper we go in the
dependency tree, the more specialised the options become and the more
expertise they require.

I agree that keeping vendor selection behind EXPERT reduces exposure
to configuration combinations that may receive limited testing. But if
there is a bug in Kconfig, is limiting exposure the correct strategy?
In the end, it just hides a genuine bug without addressing the root
cause.


Yours sincerely,
Vincent Mailhol

Re: [PATCH 0/3] x86: Make processor vendor selection available without EXPERT

[Vincent Mailhol]

On 31/10/2026 at 22:43, Borislav Petkov wrote:
> On Sat, Oct 31, 2026 at 08:51:48AM +0100, Vincent Mailhol wrote:
>> Restricting a kernel build to a known CPU vendor currently requires
>> enabling EXPERT.
>>
>> Make PROCESSOR_SELECT available without EXPERT. It remains disabled by
>> default, preserving support for all applicable CPU vendors in existing
>> configurations.
> 
> What I am not seeing is git archeology about why it is behind EXPERT and
> whether that reason is or is not valid anymore.

PROCESSOR_SELECT was introduced in 2008 by commit 8d02c2110b3f ("x86:
configuration options to compile out x86 CPU support code"). At that
time, it was gated by CONFIG_EMBEDDED with space savings given as the
main motivation. In the thread [1], Bodo pointed out that this wasn't
specific to embedded systems but his comment didn't get any replies.

Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to
CONFIG_EXPERT") then did a treewide renaming. The commit explains that
EMBEDDED already covered nonstandard configurations beyond embedded
systems but does not give a PROCESSOR_SELECT-specific rationale.

Beyond Bodo's unanswered comment, I did not find further discussion of
the relevance of PROCESSOR_SELECT for non-embedded machines or the
Kconfig user experience. The main point I am raising in this series is
how easily users should be able to disable all the features specific
to CPU vendors they do not need. I think this aspect deserves further
discussion.

Finally, the size savings have changed since 2008. As reported in my
tests, an AMD-only build reduces vmlinux.o size by 8.88%. What used to
be a micro-optimization back then now has a much bigger impact.

[1] https://lore.kernel.org/all/E1KRp7q-0001pd-61@be1.7eggert.dyndns.org/


Yours sincerely,
Vincent Mailhol