[PATCH v3 00/10] x86: 32-bit cleanups

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* [PATCH v3 00/10] x86: 32-bit cleanups
@ 2025-02-26 21:37 Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b Arnd Bergmann
                   ` (10 more replies)
  0 siblings, 11 replies; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

While looking at 32-bit arm cleanups, I came across some related topics
on x86 and ended up making a series for those as well.

Primarily this is about running 32-bit kernels on 64-bit hardware,
which usually works but should probably be discouraged more clearly by
only providing support for features that are used on real 32-bit hardware:

I found only a few 2003-era high-end servers (HP DL740 and DL760 G2)
that were the only possible remaining uses of HIGHMEM64G and BIGSMP after
the removal of 32-bit NUMA machines in 2014. Similarly, there is only
one generation of hardware with support for VT-x.  All these features
can be removed without hurting users.

In the CPU selection, building a 32-bit kernel optimized for AMD K8
or Intel Core2 is anachronistic, so instead only 32-bit CPU types need
to be offered as optimization targets. The "generic" target on 64-bit
turned out to be slightly broken, so I included a fix for that as well.

Changes since v2:

 - Add a patch for EISA
 - keep PHYS_ADDR_T_64BIT enabled for PAE kernels
 - drop the Kconfig.platforms and CONFIG_X86_64_NATIVE patches for now
 - improve changelog texts

Changes since v1:

 - Don't include patch to drop 32-bit KVM support for now
 - Drop patch for 64-bit Silverlake support
 - Drop 64-bit ISA level selection, only fix default
 - Rework MID patch based on comments
 - Add a patch to reorganize platform selection
 - Add a patch to add -march=native compilation


Arnd Bergmann (10):
  x86/Kconfig: Geode CPU has cmpxchg8b
  x86: drop 32-bit "bigsmp" machine support
  x86: rework CONFIG_GENERIC_CPU compiler flags
  x86: drop configuration options for early 64-bit CPUs
  x86: remove HIGHMEM64G support
  x86: drop SWIOTLB for PAE
  x86: drop support for CONFIG_HIGHPTE
  x86: document X86_INTEL_MID as 64-bit-only
  x86: remove old STA2x11 support
  x86: only allow EISA for 32-bit

 Documentation/admin-guide/kdump/kdump.rst     |   4 -
 .../admin-guide/kernel-parameters.txt         |  11 -
 Documentation/arch/x86/usb-legacy-support.rst |  11 +-
 arch/x86/Kconfig                              | 156 +++---------
 arch/x86/Kconfig.cpu                          |  97 ++------
 arch/x86/Makefile                             |  16 +-
 arch/x86/Makefile_32.cpu                      |   5 +-
 arch/x86/configs/xen.config                   |   2 -
 arch/x86/include/asm/page_32_types.h          |   4 +-
 arch/x86/include/asm/pgalloc.h                |   5 -
 arch/x86/include/asm/sta2x11.h                |  13 -
 arch/x86/include/asm/vermagic.h               |   4 -
 arch/x86/kernel/apic/Makefile                 |   3 -
 arch/x86/kernel/apic/apic.c                   |   3 -
 arch/x86/kernel/apic/bigsmp_32.c              | 105 --------
 arch/x86/kernel/apic/local.h                  |  13 -
 arch/x86/kernel/apic/probe_32.c               |  29 ---
 arch/x86/mm/init_32.c                         |   9 +-
 arch/x86/mm/pgtable.c                         |  27 +-
 arch/x86/pci/Makefile                         |   2 -
 arch/x86/pci/sta2x11-fixup.c                  | 233 ------------------
 drivers/misc/mei/Kconfig                      |   2 +-
 22 files changed, 66 insertions(+), 688 deletions(-)
 delete mode 100644 arch/x86/include/asm/sta2x11.h
 delete mode 100644 arch/x86/kernel/apic/bigsmp_32.c
 delete mode 100644 arch/x86/pci/sta2x11-fixup.c

-- 
2.39.5

To: x86@kernel.org 
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/Kconfig: Add cmpxchg8b support back to Geode CPUs tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 02/10] x86: drop 32-bit "bigsmp" machine support Arnd Bergmann
                   ` (9 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox, stable

From: Arnd Bergmann <arnd@arndb.de>

An older cleanup of mine inadvertently removed geode-gx1 and geode-lx
from the list of CPUs that are known to support a working cmpxchg8b.

Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency")
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2a7279d80460..42e6a40876ea 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -368,7 +368,7 @@ config X86_HAVE_PAE
 
 config X86_CMPXCHG64
 	def_bool y
-	depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7
+	depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7 || MGEODEGX1 || MGEODE_LX
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/Kconfig: Add cmpxchg8b support back to Geode CPUs
  2025-02-26 21:37 ` [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, stable, x86,
	linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     6ac43f2be982ea54b75206dccd33f4cf81bfdc39
Gitweb:        https://git.kernel.org/tip/6ac43f2be982ea54b75206dccd33f4cf81bfdc39
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:05 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:19:05 +01:00

x86/Kconfig: Add cmpxchg8b support back to Geode CPUs

An older cleanup of mine inadvertently removed geode-gx1 and geode-lx
from the list of CPUs that are known to support a working cmpxchg8b.

Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250226213714.4040853-2-arnd@kernel.org
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2a7279d..42e6a40 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -368,7 +368,7 @@ config X86_HAVE_PAE
 
 config X86_CMPXCHG64
 	def_bool y
-	depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7
+	depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7 || MGEODEGX1 || MGEODE_LX
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 02/10] x86: drop 32-bit "bigsmp" machine support
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/smp: Drop " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 03/10] x86: rework CONFIG_GENERIC_CPU compiler flags Arnd Bergmann
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

The x86-32 kernel used to support multiple platforms with more than eight
logical CPUs, from the 1999-2003 timeframe: Sequent NUMA-Q, IBM Summit,
Unisys ES7000 and HP F8. Support for all except the latter was dropped
back in 2014, leaving only the F8 based DL740 and DL760 G2 machines in
this catery, with up to eight single-core Socket-603 Xeon-MP processors
with hyperthreading.

Like the already removed machines, the HP F8 servers at the cost upwards
of $100k in typical configurations, but were quickly obsoleted by
their 64-bit Socket-604 cousins and the AMD Opteron.

Earlier servers with up to 8 Pentium Pro or Xeon processors remain
fully supported as they had no hyperthreading. Similarly, the more
common 4-socket Xeon-MP machines with hyperthreading using Intel
or ServerWorks chipsets continue to work without this, and all the
multi-core Xeon processors also run 64-bit kernels.

While the "bigsmp" support can also be used to run on later 64-bit
machines (including VM guests), it seems best to discourage that
and get any remaining users to update their kernels to 64-bit builds
on these. As a side-effect of this, there is also no more need to
support NUMA configurations on 32-bit x86, as all true 32-bit
NUMA platforms are already gone.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../admin-guide/kernel-parameters.txt         |   4 -
 arch/x86/Kconfig                              |  20 +---
 arch/x86/kernel/apic/Makefile                 |   3 -
 arch/x86/kernel/apic/apic.c                   |   3 -
 arch/x86/kernel/apic/bigsmp_32.c              | 105 ------------------
 arch/x86/kernel/apic/local.h                  |  13 ---
 arch/x86/kernel/apic/probe_32.c               |  29 -----
 7 files changed, 4 insertions(+), 173 deletions(-)
 delete mode 100644 arch/x86/kernel/apic/bigsmp_32.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fb8752b42ec8..8f923770a566 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -416,10 +416,6 @@
 			Format: { quiet (default) | verbose | debug }
 			Change the amount of debugging information output
 			when initialising the APIC and IO-APIC components.
-			For X86-32, this can also be used to specify an APIC
-			driver name.
-			Format: apic=driver_name
-			Examples: apic=bigsmp
 
 	apic_extnmi=	[APIC,X86,EARLY] External NMI delivery setting
 			Format: { bsp (default) | all | none }
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 87198d957e2f..4a1205b22ae2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -530,12 +530,6 @@ config X86_FRED
 	  ring transitions and exception/interrupt handling if the
 	  system supports it.
 
-config X86_BIGSMP
-	bool "Support for big SMP systems with more than 8 CPUs"
-	depends on SMP && X86_32
-	help
-	  This option is needed for the systems that have more than 8 CPUs.
-
 config X86_EXTENDED_PLATFORM
 	bool "Support for extended (non-PC) x86 platforms"
 	default y
@@ -734,8 +728,8 @@ config X86_32_NON_STANDARD
 	depends on X86_32 && SMP
 	depends on X86_EXTENDED_PLATFORM
 	help
-	  This option compiles in the bigsmp and STA2X11 default
-	  subarchitectures.  It is intended for a generic binary
+	  This option compiles in the STA2X11 default
+	  subarchitecture.  It is intended for a generic binary
 	  kernel. If you select them all, kernel will probe it one by
 	  one and will fallback to default.
 
@@ -1012,8 +1006,7 @@ config NR_CPUS_RANGE_BEGIN
 config NR_CPUS_RANGE_END
 	int
 	depends on X86_32
-	default   64 if  SMP &&  X86_BIGSMP
-	default    8 if  SMP && !X86_BIGSMP
+	default    8 if  SMP
 	default    1 if !SMP
 
 config NR_CPUS_RANGE_END
@@ -1026,7 +1019,6 @@ config NR_CPUS_RANGE_END
 config NR_CPUS_DEFAULT
 	int
 	depends on X86_32
-	default   32 if  X86_BIGSMP
 	default    8 if  SMP
 	default    1 if !SMP
 
@@ -1573,8 +1565,7 @@ config AMD_MEM_ENCRYPT
 config NUMA
 	bool "NUMA Memory Allocation and Scheduler Support"
 	depends on SMP
-	depends on X86_64 || (X86_32 && HIGHMEM64G && X86_BIGSMP)
-	default y if X86_BIGSMP
+	depends on X86_64
 	select USE_PERCPU_NUMA_NODE_ID
 	select OF_NUMA if OF
 	help
@@ -1587,9 +1578,6 @@ config NUMA
 	  For 64-bit this is recommended if the system is Intel Core i7
 	  (or later), AMD Opteron, or EM64T NUMA.
 
-	  For 32-bit this is only needed if you boot a 32-bit
-	  kernel on a 64-bit NUMA platform.
-
 	  Otherwise, you should say N.
 
 config AMD_NUMA
diff --git a/arch/x86/kernel/apic/Makefile b/arch/x86/kernel/apic/Makefile
index 3bf0487cf3b7..52d1808ee360 100644
--- a/arch/x86/kernel/apic/Makefile
+++ b/arch/x86/kernel/apic/Makefile
@@ -23,8 +23,5 @@ obj-$(CONFIG_X86_X2APIC)	+= x2apic_cluster.o
 obj-y				+= apic_flat_64.o
 endif
 
-# APIC probe will depend on the listing order here
-obj-$(CONFIG_X86_BIGSMP)	+= bigsmp_32.o
-
 # For 32bit, probe_32 need to be listed last
 obj-$(CONFIG_X86_LOCAL_APIC)	+= probe_$(BITS).o
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e893dc6f11c1..ddca8da6d468 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1371,8 +1371,6 @@ void __init apic_intr_mode_init(void)
 
 	x86_64_probe_apic();
 
-	x86_32_install_bigsmp();
-
 	if (x86_platform.apic_post_init)
 		x86_platform.apic_post_init();
 
@@ -1674,7 +1672,6 @@ static __init void apic_read_boot_cpu_id(bool x2apic)
 		boot_cpu_apic_version = GET_APIC_VERSION(apic_read(APIC_LVR));
 	}
 	topology_register_boot_apic(boot_cpu_physical_apicid);
-	x86_32_probe_bigsmp_early();
 }
 
 #ifdef CONFIG_X86_X2APIC
diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c
deleted file mode 100644
index 9285d500d5b4..000000000000
--- a/arch/x86/kernel/apic/bigsmp_32.c
+++ /dev/null
@@ -1,105 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * APIC driver for "bigsmp" xAPIC machines with more than 8 virtual CPUs.
- *
- * Drives the local APIC in "clustered mode".
- */
-#include <linux/cpumask.h>
-#include <linux/dmi.h>
-#include <linux/smp.h>
-
-#include <asm/apic.h>
-#include <asm/io_apic.h>
-
-#include "local.h"
-
-static u32 bigsmp_get_apic_id(u32 x)
-{
-	return (x >> 24) & 0xFF;
-}
-
-static void bigsmp_send_IPI_allbutself(int vector)
-{
-	default_send_IPI_mask_allbutself_phys(cpu_online_mask, vector);
-}
-
-static void bigsmp_send_IPI_all(int vector)
-{
-	default_send_IPI_mask_sequence_phys(cpu_online_mask, vector);
-}
-
-static int dmi_bigsmp; /* can be set by dmi scanners */
-
-static int hp_ht_bigsmp(const struct dmi_system_id *d)
-{
-	printk(KERN_NOTICE "%s detected: force use of apic=bigsmp\n", d->ident);
-	dmi_bigsmp = 1;
-
-	return 0;
-}
-
-
-static const struct dmi_system_id bigsmp_dmi_table[] = {
-	{ hp_ht_bigsmp, "HP ProLiant DL760 G2",
-		{	DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-			DMI_MATCH(DMI_BIOS_VERSION, "P44-"),
-		}
-	},
-
-	{ hp_ht_bigsmp, "HP ProLiant DL740",
-		{	DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-			DMI_MATCH(DMI_BIOS_VERSION, "P47-"),
-		}
-	},
-	{ } /* NULL entry stops DMI scanning */
-};
-
-static int probe_bigsmp(void)
-{
-	return dmi_check_system(bigsmp_dmi_table);
-}
-
-static struct apic apic_bigsmp __ro_after_init = {
-
-	.name				= "bigsmp",
-	.probe				= probe_bigsmp,
-
-	.dest_mode_logical		= false,
-
-	.disable_esr			= 1,
-
-	.cpu_present_to_apicid		= default_cpu_present_to_apicid,
-
-	.max_apic_id			= 0xFE,
-	.get_apic_id			= bigsmp_get_apic_id,
-
-	.calc_dest_apicid		= apic_default_calc_apicid,
-
-	.send_IPI			= default_send_IPI_single_phys,
-	.send_IPI_mask			= default_send_IPI_mask_sequence_phys,
-	.send_IPI_mask_allbutself	= NULL,
-	.send_IPI_allbutself		= bigsmp_send_IPI_allbutself,
-	.send_IPI_all			= bigsmp_send_IPI_all,
-	.send_IPI_self			= default_send_IPI_self,
-
-	.read				= native_apic_mem_read,
-	.write				= native_apic_mem_write,
-	.eoi				= native_apic_mem_eoi,
-	.icr_read			= native_apic_icr_read,
-	.icr_write			= native_apic_icr_write,
-	.wait_icr_idle			= apic_mem_wait_icr_idle,
-	.safe_wait_icr_idle		= apic_mem_wait_icr_idle_timeout,
-};
-
-bool __init apic_bigsmp_possible(bool cmdline_override)
-{
-	return apic == &apic_bigsmp || !cmdline_override;
-}
-
-void __init apic_bigsmp_force(void)
-{
-	if (apic != &apic_bigsmp)
-		apic_install_driver(&apic_bigsmp);
-}
-
-apic_driver(apic_bigsmp);
diff --git a/arch/x86/kernel/apic/local.h b/arch/x86/kernel/apic/local.h
index 842fe28496be..bdcf609eb283 100644
--- a/arch/x86/kernel/apic/local.h
+++ b/arch/x86/kernel/apic/local.h
@@ -65,17 +65,4 @@ void default_send_IPI_self(int vector);
 void default_send_IPI_mask_sequence_logical(const struct cpumask *mask, int vector);
 void default_send_IPI_mask_allbutself_logical(const struct cpumask *mask, int vector);
 void default_send_IPI_mask_logical(const struct cpumask *mask, int vector);
-void x86_32_probe_bigsmp_early(void);
-void x86_32_install_bigsmp(void);
-#else
-static inline void x86_32_probe_bigsmp_early(void) { }
-static inline void x86_32_install_bigsmp(void) { }
-#endif
-
-#ifdef CONFIG_X86_BIGSMP
-bool apic_bigsmp_possible(bool cmdline_selected);
-void apic_bigsmp_force(void);
-#else
-static inline bool apic_bigsmp_possible(bool cmdline_selected) { return false; };
-static inline void apic_bigsmp_force(void) { }
 #endif
diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c
index f75ee345c02d..87bc9e7ca5d6 100644
--- a/arch/x86/kernel/apic/probe_32.c
+++ b/arch/x86/kernel/apic/probe_32.c
@@ -93,35 +93,6 @@ static int __init parse_apic(char *arg)
 }
 early_param("apic", parse_apic);
 
-void __init x86_32_probe_bigsmp_early(void)
-{
-	if (nr_cpu_ids <= 8 || xen_pv_domain())
-		return;
-
-	if (IS_ENABLED(CONFIG_X86_BIGSMP)) {
-		switch (boot_cpu_data.x86_vendor) {
-		case X86_VENDOR_INTEL:
-			if (!APIC_XAPIC(boot_cpu_apic_version))
-				break;
-			/* P4 and above */
-			fallthrough;
-		case X86_VENDOR_HYGON:
-		case X86_VENDOR_AMD:
-			if (apic_bigsmp_possible(cmdline_apic))
-				return;
-			break;
-		}
-	}
-	pr_info("Limiting to 8 possible CPUs\n");
-	set_nr_cpu_ids(8);
-}
-
-void __init x86_32_install_bigsmp(void)
-{
-	if (nr_cpu_ids > 8 && !xen_pv_domain())
-		apic_bigsmp_force();
-}
-
 void __init x86_32_probe_apic(void)
 {
 	if (!cmdline_apic) {
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/smp: Drop 32-bit "bigsmp" machine support
  2025-02-26 21:37 ` [PATCH v3 02/10] x86: drop 32-bit "bigsmp" machine support Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     0abf508675c0dbbca6a387842f90db60756c4af5
Gitweb:        https://git.kernel.org/tip/0abf508675c0dbbca6a387842f90db60756c4af5
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:06 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:19:05 +01:00

x86/smp: Drop 32-bit "bigsmp" machine support

The x86-32 kernel used to support multiple platforms with more than eight
logical CPUs, from the 1999-2003 timeframe: Sequent NUMA-Q, IBM Summit,
Unisys ES7000 and HP F8. Support for all except the latter was dropped
back in 2014, leaving only the F8 based DL740 and DL760 G2 machines in
this catery, with up to eight single-core Socket-603 Xeon-MP processors
with hyperthreading.

Like the already removed machines, the HP F8 servers at the time cost
upwards of $100k in typical configurations, but were quickly obsoleted
by their 64-bit Socket-604 cousins and the AMD Opteron.

Earlier servers with up to 8 Pentium Pro or Xeon processors remain
fully supported as they had no hyperthreading. Similarly, the more
common 4-socket Xeon-MP machines with hyperthreading using Intel
or ServerWorks chipsets continue to work without this, and all the
multi-core Xeon processors also run 64-bit kernels.

While the "bigsmp" support can also be used to run on later 64-bit
machines (including VM guests), it seems best to discourage that
and get any remaining users to update their kernels to 64-bit builds
on these. As a side-effect of this, there is also no more need to
support NUMA configurations on 32-bit x86, as all true 32-bit
NUMA platforms are already gone.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-3-arnd@kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |   4 +-
 arch/x86/Kconfig                                |  20 +---
 arch/x86/kernel/apic/Makefile                   |   3 +-
 arch/x86/kernel/apic/apic.c                     |   3 +-
 arch/x86/kernel/apic/bigsmp_32.c                | 105 +---------------
 arch/x86/kernel/apic/local.h                    |  13 +--
 arch/x86/kernel/apic/probe_32.c                 |  29 +----
 7 files changed, 4 insertions(+), 173 deletions(-)
 delete mode 100644 arch/x86/kernel/apic/bigsmp_32.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fb8752b..8f92377 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -416,10 +416,6 @@
 			Format: { quiet (default) | verbose | debug }
 			Change the amount of debugging information output
 			when initialising the APIC and IO-APIC components.
-			For X86-32, this can also be used to specify an APIC
-			driver name.
-			Format: apic=driver_name
-			Examples: apic=bigsmp
 
 	apic_extnmi=	[APIC,X86,EARLY] External NMI delivery setting
 			Format: { bsp (default) | all | none }
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d581634..887b77b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -531,12 +531,6 @@ config X86_FRED
 	  ring transitions and exception/interrupt handling if the
 	  system supports it.
 
-config X86_BIGSMP
-	bool "Support for big SMP systems with more than 8 CPUs"
-	depends on SMP && X86_32
-	help
-	  This option is needed for the systems that have more than 8 CPUs.
-
 config X86_EXTENDED_PLATFORM
 	bool "Support for extended (non-PC) x86 platforms"
 	default y
@@ -735,8 +729,8 @@ config X86_32_NON_STANDARD
 	depends on X86_32 && SMP
 	depends on X86_EXTENDED_PLATFORM
 	help
-	  This option compiles in the bigsmp and STA2X11 default
-	  subarchitectures.  It is intended for a generic binary
+	  This option compiles in the STA2X11 default
+	  subarchitecture.  It is intended for a generic binary
 	  kernel. If you select them all, kernel will probe it one by
 	  one and will fallback to default.
 
@@ -1013,8 +1007,7 @@ config NR_CPUS_RANGE_BEGIN
 config NR_CPUS_RANGE_END
 	int
 	depends on X86_32
-	default   64 if  SMP &&  X86_BIGSMP
-	default    8 if  SMP && !X86_BIGSMP
+	default    8 if  SMP
 	default    1 if !SMP
 
 config NR_CPUS_RANGE_END
@@ -1027,7 +1020,6 @@ config NR_CPUS_RANGE_END
 config NR_CPUS_DEFAULT
 	int
 	depends on X86_32
-	default   32 if  X86_BIGSMP
 	default    8 if  SMP
 	default    1 if !SMP
 
@@ -1574,8 +1566,7 @@ config AMD_MEM_ENCRYPT
 config NUMA
 	bool "NUMA Memory Allocation and Scheduler Support"
 	depends on SMP
-	depends on X86_64 || (X86_32 && HIGHMEM64G && X86_BIGSMP)
-	default y if X86_BIGSMP
+	depends on X86_64
 	select USE_PERCPU_NUMA_NODE_ID
 	select OF_NUMA if OF
 	help
@@ -1588,9 +1579,6 @@ config NUMA
 	  For 64-bit this is recommended if the system is Intel Core i7
 	  (or later), AMD Opteron, or EM64T NUMA.
 
-	  For 32-bit this is only needed if you boot a 32-bit
-	  kernel on a 64-bit NUMA platform.
-
 	  Otherwise, you should say N.
 
 config AMD_NUMA
diff --git a/arch/x86/kernel/apic/Makefile b/arch/x86/kernel/apic/Makefile
index 3bf0487..52d1808 100644
--- a/arch/x86/kernel/apic/Makefile
+++ b/arch/x86/kernel/apic/Makefile
@@ -23,8 +23,5 @@ obj-$(CONFIG_X86_X2APIC)	+= x2apic_cluster.o
 obj-y				+= apic_flat_64.o
 endif
 
-# APIC probe will depend on the listing order here
-obj-$(CONFIG_X86_BIGSMP)	+= bigsmp_32.o
-
 # For 32bit, probe_32 need to be listed last
 obj-$(CONFIG_X86_LOCAL_APIC)	+= probe_$(BITS).o
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e893dc6..ddca8da 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1371,8 +1371,6 @@ void __init apic_intr_mode_init(void)
 
 	x86_64_probe_apic();
 
-	x86_32_install_bigsmp();
-
 	if (x86_platform.apic_post_init)
 		x86_platform.apic_post_init();
 
@@ -1674,7 +1672,6 @@ static __init void apic_read_boot_cpu_id(bool x2apic)
 		boot_cpu_apic_version = GET_APIC_VERSION(apic_read(APIC_LVR));
 	}
 	topology_register_boot_apic(boot_cpu_physical_apicid);
-	x86_32_probe_bigsmp_early();
 }
 
 #ifdef CONFIG_X86_X2APIC
diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c
deleted file mode 100644
index 9285d50..0000000
--- a/arch/x86/kernel/apic/bigsmp_32.c
+++ /dev/null
@@ -1,105 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * APIC driver for "bigsmp" xAPIC machines with more than 8 virtual CPUs.
- *
- * Drives the local APIC in "clustered mode".
- */
-#include <linux/cpumask.h>
-#include <linux/dmi.h>
-#include <linux/smp.h>
-
-#include <asm/apic.h>
-#include <asm/io_apic.h>
-
-#include "local.h"
-
-static u32 bigsmp_get_apic_id(u32 x)
-{
-	return (x >> 24) & 0xFF;
-}
-
-static void bigsmp_send_IPI_allbutself(int vector)
-{
-	default_send_IPI_mask_allbutself_phys(cpu_online_mask, vector);
-}
-
-static void bigsmp_send_IPI_all(int vector)
-{
-	default_send_IPI_mask_sequence_phys(cpu_online_mask, vector);
-}
-
-static int dmi_bigsmp; /* can be set by dmi scanners */
-
-static int hp_ht_bigsmp(const struct dmi_system_id *d)
-{
-	printk(KERN_NOTICE "%s detected: force use of apic=bigsmp\n", d->ident);
-	dmi_bigsmp = 1;
-
-	return 0;
-}
-
-
-static const struct dmi_system_id bigsmp_dmi_table[] = {
-	{ hp_ht_bigsmp, "HP ProLiant DL760 G2",
-		{	DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-			DMI_MATCH(DMI_BIOS_VERSION, "P44-"),
-		}
-	},
-
-	{ hp_ht_bigsmp, "HP ProLiant DL740",
-		{	DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-			DMI_MATCH(DMI_BIOS_VERSION, "P47-"),
-		}
-	},
-	{ } /* NULL entry stops DMI scanning */
-};
-
-static int probe_bigsmp(void)
-{
-	return dmi_check_system(bigsmp_dmi_table);
-}
-
-static struct apic apic_bigsmp __ro_after_init = {
-
-	.name				= "bigsmp",
-	.probe				= probe_bigsmp,
-
-	.dest_mode_logical		= false,
-
-	.disable_esr			= 1,
-
-	.cpu_present_to_apicid		= default_cpu_present_to_apicid,
-
-	.max_apic_id			= 0xFE,
-	.get_apic_id			= bigsmp_get_apic_id,
-
-	.calc_dest_apicid		= apic_default_calc_apicid,
-
-	.send_IPI			= default_send_IPI_single_phys,
-	.send_IPI_mask			= default_send_IPI_mask_sequence_phys,
-	.send_IPI_mask_allbutself	= NULL,
-	.send_IPI_allbutself		= bigsmp_send_IPI_allbutself,
-	.send_IPI_all			= bigsmp_send_IPI_all,
-	.send_IPI_self			= default_send_IPI_self,
-
-	.read				= native_apic_mem_read,
-	.write				= native_apic_mem_write,
-	.eoi				= native_apic_mem_eoi,
-	.icr_read			= native_apic_icr_read,
-	.icr_write			= native_apic_icr_write,
-	.wait_icr_idle			= apic_mem_wait_icr_idle,
-	.safe_wait_icr_idle		= apic_mem_wait_icr_idle_timeout,
-};
-
-bool __init apic_bigsmp_possible(bool cmdline_override)
-{
-	return apic == &apic_bigsmp || !cmdline_override;
-}
-
-void __init apic_bigsmp_force(void)
-{
-	if (apic != &apic_bigsmp)
-		apic_install_driver(&apic_bigsmp);
-}
-
-apic_driver(apic_bigsmp);
diff --git a/arch/x86/kernel/apic/local.h b/arch/x86/kernel/apic/local.h
index 842fe28..bdcf609 100644
--- a/arch/x86/kernel/apic/local.h
+++ b/arch/x86/kernel/apic/local.h
@@ -65,17 +65,4 @@ void default_send_IPI_self(int vector);
 void default_send_IPI_mask_sequence_logical(const struct cpumask *mask, int vector);
 void default_send_IPI_mask_allbutself_logical(const struct cpumask *mask, int vector);
 void default_send_IPI_mask_logical(const struct cpumask *mask, int vector);
-void x86_32_probe_bigsmp_early(void);
-void x86_32_install_bigsmp(void);
-#else
-static inline void x86_32_probe_bigsmp_early(void) { }
-static inline void x86_32_install_bigsmp(void) { }
-#endif
-
-#ifdef CONFIG_X86_BIGSMP
-bool apic_bigsmp_possible(bool cmdline_selected);
-void apic_bigsmp_force(void);
-#else
-static inline bool apic_bigsmp_possible(bool cmdline_selected) { return false; };
-static inline void apic_bigsmp_force(void) { }
 #endif
diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c
index f75ee34..87bc9e7 100644
--- a/arch/x86/kernel/apic/probe_32.c
+++ b/arch/x86/kernel/apic/probe_32.c
@@ -93,35 +93,6 @@ static int __init parse_apic(char *arg)
 }
 early_param("apic", parse_apic);
 
-void __init x86_32_probe_bigsmp_early(void)
-{
-	if (nr_cpu_ids <= 8 || xen_pv_domain())
-		return;
-
-	if (IS_ENABLED(CONFIG_X86_BIGSMP)) {
-		switch (boot_cpu_data.x86_vendor) {
-		case X86_VENDOR_INTEL:
-			if (!APIC_XAPIC(boot_cpu_apic_version))
-				break;
-			/* P4 and above */
-			fallthrough;
-		case X86_VENDOR_HYGON:
-		case X86_VENDOR_AMD:
-			if (apic_bigsmp_possible(cmdline_apic))
-				return;
-			break;
-		}
-	}
-	pr_info("Limiting to 8 possible CPUs\n");
-	set_nr_cpu_ids(8);
-}
-
-void __init x86_32_install_bigsmp(void)
-{
-	if (nr_cpu_ids > 8 && !xen_pv_domain())
-		apic_bigsmp_force();
-}
-
 void __init x86_32_probe_apic(void)
 {
 	if (!cmdline_apic) {

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 03/10] x86: rework CONFIG_GENERIC_CPU compiler flags
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 02/10] x86: drop 32-bit "bigsmp" machine support Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/build: Rework " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 04/10] x86: drop configuration options for early 64-bit CPUs Arnd Bergmann
                   ` (7 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

Building an x86-64 kernel with CONFIG_GENERIC_CPU is documented to
run on all CPUs, but the Makefile does not actually pass an -march=
argument, instead relying on the default that was used to configure
the toolchain.

In many cases, gcc will be configured to -march=x86-64 or -march=k8
for maximum compatibility, but in other cases a distribution default
may be either raised to a more recent ISA, or set to -march=native
to build for the CPU used for compilation. This still works in the
case of building a custom kernel for the local machine.

The point where it breaks down is building a kernel for another
machine that is older the the default target. Changing the default
to -march=x86-64 would make it work reliable, but possibly produce
worse code on distros that intentionally default to a newer ISA.

To allow reliably building a kernel for either the oldest x86-64
CPUs, pass the -march=x86-64 flag to the compiler. This was not
possible in early versions of x86-64 gcc, but works on all currently
supported versions down to at least gcc-5.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5b773b34768d..5af3172fd51c 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -183,14 +183,14 @@ else
         cflags-$(CONFIG_MPSC)		+= -march=nocona
         cflags-$(CONFIG_MCORE2)		+= -march=core2
         cflags-$(CONFIG_MATOM)		+= -march=atom
-        cflags-$(CONFIG_GENERIC_CPU)	+= -mtune=generic
+        cflags-$(CONFIG_GENERIC_CPU)	+= -march=x86-64 -mtune=generic
         KBUILD_CFLAGS += $(cflags-y)
 
         rustflags-$(CONFIG_MK8)		+= -Ctarget-cpu=k8
         rustflags-$(CONFIG_MPSC)	+= -Ctarget-cpu=nocona
         rustflags-$(CONFIG_MCORE2)	+= -Ctarget-cpu=core2
         rustflags-$(CONFIG_MATOM)	+= -Ctarget-cpu=atom
-        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ztune-cpu=generic
+        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ctarget-cpu=x86-64 -Ztune-cpu=generic
         KBUILD_RUSTFLAGS += $(rustflags-y)
 
         KBUILD_CFLAGS += -mno-red-zone
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/build: Rework CONFIG_GENERIC_CPU compiler flags
  2025-02-26 21:37 ` [PATCH v3 03/10] x86: rework CONFIG_GENERIC_CPU compiler flags Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     fc2d5cbe541032e74a66599ba843803cebbfed0e
Gitweb:        https://git.kernel.org/tip/fc2d5cbe541032e74a66599ba843803cebbfed0e
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:07 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:19:05 +01:00

x86/build: Rework CONFIG_GENERIC_CPU compiler flags

Building an x86-64 kernel with CONFIG_GENERIC_CPU is documented to
run on all CPUs, but the Makefile does not actually pass an -march=
argument, instead relying on the default that was used to configure
the toolchain.

In many cases, gcc will be configured to -march=x86-64 or -march=k8
for maximum compatibility, but in other cases a distribution default
may be either raised to a more recent ISA, or set to -march=native
to build for the CPU used for compilation. This still works in the
case of building a custom kernel for the local machine.

The point where it breaks down is building a kernel for another
machine that is older the the default target. Changing the default
to -march=x86-64 would make it work reliable, but possibly produce
worse code on distros that intentionally default to a newer ISA.

To allow reliably building a kernel for either the oldest x86-64
CPUs, pass the -march=x86-64 flag to the compiler. This was not
possible in early versions of x86-64 gcc, but works on all currently
supported versions down to at least gcc-5.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-4-arnd@kernel.org
---
 arch/x86/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5b773b3..5af3172 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -183,14 +183,14 @@ else
         cflags-$(CONFIG_MPSC)		+= -march=nocona
         cflags-$(CONFIG_MCORE2)		+= -march=core2
         cflags-$(CONFIG_MATOM)		+= -march=atom
-        cflags-$(CONFIG_GENERIC_CPU)	+= -mtune=generic
+        cflags-$(CONFIG_GENERIC_CPU)	+= -march=x86-64 -mtune=generic
         KBUILD_CFLAGS += $(cflags-y)

         rustflags-$(CONFIG_MK8)		+= -Ctarget-cpu=k8
         rustflags-$(CONFIG_MPSC)	+= -Ctarget-cpu=nocona
         rustflags-$(CONFIG_MCORE2)	+= -Ctarget-cpu=core2
         rustflags-$(CONFIG_MATOM)	+= -Ctarget-cpu=atom
-        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ztune-cpu=generic
+        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ctarget-cpu=x86-64 -Ztune-cpu=generic
         KBUILD_RUSTFLAGS += $(rustflags-y)

         KBUILD_CFLAGS += -mno-red-zone

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 04/10] x86: drop configuration options for early 64-bit CPUs
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (2 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 03/10] x86: rework CONFIG_GENERIC_CPU compiler flags Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/cpu: Drop " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 05/10] x86: remove HIGHMEM64G support Arnd Bergmann
                   ` (6 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

The x86 CPU selection menu is confusing for a number of reasons:

When configuring 32-bit kernels, it shows a small number of early 64-bit
microarchitectures (K8, Core 2) but not the regular generic 64-bit target
that is the normal default.  There is no longer a reason to run 32-bit
kernels on production 64-bit systems, so only actual 32-bit CPUs need
to be shown here.

When configuring 64-bit kernels, the options also pointless as there is
no way to pick any CPU from the past 15 years, leaving GENERIC_CPU as
the only sensible choice.

Address both of the above by removing the obsolete options and making
all 64-bit kernels run on both Intel and AMD CPUs from any generation.
Testing generic 32-bit kernels on 64-bit hardware remains possible,
just not building a 32-bit kernel that requires a 64-bit CPU.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig.cpu            | 95 +++++----------------------------
 arch/x86/Makefile               | 16 +-----
 arch/x86/Makefile_32.cpu        |  5 +-
 arch/x86/include/asm/vermagic.h |  4 --
 drivers/misc/mei/Kconfig        |  2 +-
 5 files changed, 18 insertions(+), 104 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 42e6a40876ea..8fcb8ccee44b 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -1,9 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 # Put here option for CPU selection and depending optimization
 choice
-	prompt "Processor family"
-	default M686 if X86_32
-	default GENERIC_CPU if X86_64
+	prompt "x86-32 Processor family"
+	depends on X86_32
+	default M686
 	help
 	  This is the processor type of your CPU. This information is
 	  used for optimizing purposes. In order to compile a kernel
@@ -31,7 +31,6 @@ choice
 	  - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
 	  - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
 	  - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
-	  - "Opteron/Athlon64/Hammer/K8" for all K8 and newer AMD CPUs.
 	  - "Crusoe" for the Transmeta Crusoe series.
 	  - "Efficeon" for the Transmeta Efficeon series.
 	  - "Winchip-C6" for original IDT Winchip.
@@ -42,13 +41,10 @@ choice
 	  - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
 	  - "VIA C3-2" for VIA C3-2 "Nehemiah" (model 9 and above).
 	  - "VIA C7" for VIA C7.
-	  - "Intel P4" for the Pentium 4/Netburst microarchitecture.
-	  - "Core 2/newer Xeon" for all core2 and newer Intel CPUs.
 	  - "Intel Atom" for the Atom-microarchitecture CPUs.
-	  - "Generic-x86-64" for a kernel which runs on any x86-64 CPU.
 
 	  See each option's help text for additional details. If you don't know
-	  what to do, choose "486".
+	  what to do, choose "Pentium-Pro".
 
 config M486SX
 	bool "486SX"
@@ -114,11 +110,11 @@ config MPENTIUMIII
 	  extensions.
 
 config MPENTIUMM
-	bool "Pentium M"
+	bool "Pentium M/Pentium Dual Core/Core Solo/Core Duo"
 	depends on X86_32
 	help
 	  Select this for Intel Pentium M (not Pentium-4 M)
-	  notebook chips.
+	  "Merom" Core Solo/Duo notebook chips
 
 config MPENTIUM4
 	bool "Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon"
@@ -139,22 +135,10 @@ config MPENTIUM4
 		-Mobile Pentium 4
 		-Mobile Pentium 4 M
 		-Extreme Edition (Gallatin)
-		-Prescott
-		-Prescott 2M
-		-Cedar Mill
-		-Presler
-		-Smithfiled
 	    Xeons (Intel Xeon, Xeon MP, Xeon LV, Xeon MV) corename:
 		-Foster
 		-Prestonia
 		-Gallatin
-		-Nocona
-		-Irwindale
-		-Cranford
-		-Potomac
-		-Paxville
-		-Dempsey
-
 
 config MK6
 	bool "K6/K6-II/K6-III"
@@ -172,13 +156,6 @@ config MK7
 	  some extended instructions, and passes appropriate optimization
 	  flags to GCC.
 
-config MK8
-	bool "Opteron/Athlon64/Hammer/K8"
-	help
-	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.
-	  Enables use of some extended instructions, and passes appropriate
-	  optimization flags to GCC.
-
 config MCRUSOE
 	bool "Crusoe"
 	depends on X86_32
@@ -258,42 +235,14 @@ config MVIAC7
 	  Select this for a VIA C7.  Selecting this uses the correct cache
 	  shift and tells gcc to treat the CPU as a 686.
 
-config MPSC
-	bool "Intel P4 / older Netburst based Xeon"
-	depends on X86_64
-	help
-	  Optimize for Intel Pentium 4, Pentium D and older Nocona/Dempsey
-	  Xeon CPUs with Intel 64bit which is compatible with x86-64.
-	  Note that the latest Xeons (Xeon 51xx and 53xx) are not based on the
-	  Netburst core and shouldn't use this option. You can distinguish them
-	  using the cpu family field
-	  in /proc/cpuinfo. Family 15 is an older Xeon, Family 6 a newer one.
-
-config MCORE2
-	bool "Core 2/newer Xeon"
-	help
-
-	  Select this for Intel Core 2 and newer Core 2 Xeons (Xeon 51xx and
-	  53xx) CPUs. You can distinguish newer from older Xeons by the CPU
-	  family in /proc/cpuinfo. Newer ones have 6 and older ones 15
-	  (not a typo)
-
 config MATOM
 	bool "Intel Atom"
 	help
-
 	  Select this for the Intel Atom platform. Intel Atom CPUs have an
 	  in-order pipelining architecture and thus can benefit from
 	  accordingly optimized code. Use a recent GCC with specific Atom
 	  support in order to fully benefit from selecting this option.
 
-config GENERIC_CPU
-	bool "Generic-x86-64"
-	depends on X86_64
-	help
-	  Generic x86-64 CPU.
-	  Run equally well on all x86-64 CPUs.
-
 endchoice
 
 config X86_GENERIC
@@ -317,8 +266,8 @@ config X86_INTERNODE_CACHE_SHIFT
 
 config X86_L1_CACHE_SHIFT
 	int
-	default "7" if MPENTIUM4 || MPSC
-	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU
+	default "7" if MPENTIUM4
+	default "6" if MK7 || MPENTIUMM || MATOM || MVIAC7 || X86_GENERIC || X86_64
 	default "4" if MELAN || M486SX || M486 || MGEODEGX1
 	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
 
@@ -336,35 +285,19 @@ config X86_ALIGNMENT_16
 
 config X86_INTEL_USERCOPY
 	def_bool y
-	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MCORE2
+	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK7 || MEFFICEON
 
 config X86_USE_PPRO_CHECKSUM
 	def_bool y
-	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM
-
-#
-# P6_NOPs are a relatively minor optimization that require a family >=
-# 6 processor, except that it is broken on certain VIA chips.
-# Furthermore, AMD chips prefer a totally different sequence of NOPs
-# (which work on all CPUs).  In addition, it looks like Virtual PC
-# does not understand them.
-#
-# As a result, disallow these if we're not compiling for X86_64 (these
-# NOPs do work on all x86-64 capable chips); the list of processors in
-# the right-hand clause are the cores that benefit from this optimization.
-#
-config X86_P6_NOP
-	def_bool y
-	depends on X86_64
-	depends on (MCORE2 || MPENTIUM4 || MPSC)
+	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MATOM
 
 config X86_TSC
 	def_bool y
-	depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2 || MATOM) || X86_64
+	depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MATOM) || X86_64
 
 config X86_HAVE_PAE
 	def_bool y
-	depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC7 || MCORE2 || MATOM || X86_64
+	depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC7 || MATOM || X86_64
 
 config X86_CMPXCHG64
 	def_bool y
@@ -374,12 +307,12 @@ config X86_CMPXCHG64
 # generates cmov.
 config X86_CMOV
 	def_bool y
-	depends on (MK8 || MK7 || MCORE2 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MCRUSOE || MEFFICEON || X86_64 || MATOM || MGEODE_LX)
+	depends on (MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MCRUSOE || MEFFICEON || MATOM || MGEODE_LX || X86_64)
 
 config X86_MINIMUM_CPU_FAMILY
 	int
 	default "64" if X86_64
-	default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCORE2 || MK7 || MK8)
+	default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MK7)
 	default "5" if X86_32 && X86_CMPXCHG64
 	default "4"
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5af3172fd51c..8120085b00a4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -178,20 +178,8 @@ else
 	# Use -mskip-rax-setup if supported.
 	KBUILD_CFLAGS += $(call cc-option,-mskip-rax-setup)
 
-        # FIXME - should be integrated in Makefile.cpu (Makefile_32.cpu)
-        cflags-$(CONFIG_MK8)		+= -march=k8
-        cflags-$(CONFIG_MPSC)		+= -march=nocona
-        cflags-$(CONFIG_MCORE2)		+= -march=core2
-        cflags-$(CONFIG_MATOM)		+= -march=atom
-        cflags-$(CONFIG_GENERIC_CPU)	+= -march=x86-64 -mtune=generic
-        KBUILD_CFLAGS += $(cflags-y)
-
-        rustflags-$(CONFIG_MK8)		+= -Ctarget-cpu=k8
-        rustflags-$(CONFIG_MPSC)	+= -Ctarget-cpu=nocona
-        rustflags-$(CONFIG_MCORE2)	+= -Ctarget-cpu=core2
-        rustflags-$(CONFIG_MATOM)	+= -Ctarget-cpu=atom
-        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ctarget-cpu=x86-64 -Ztune-cpu=generic
-        KBUILD_RUSTFLAGS += $(rustflags-y)
+        KBUILD_CFLAGS += -march=x86-64 -mtune=generic
+        KBUILD_RUSTFLAGS += -Ctarget-cpu=x86-64 -Ztune-cpu=generic
 
         KBUILD_CFLAGS += -mno-red-zone
         KBUILD_CFLAGS += -mcmodel=kernel
diff --git a/arch/x86/Makefile_32.cpu b/arch/x86/Makefile_32.cpu
index 94834c4b5e5e..af7de9a42752 100644
--- a/arch/x86/Makefile_32.cpu
+++ b/arch/x86/Makefile_32.cpu
@@ -24,7 +24,6 @@ cflags-$(CONFIG_MK6)		+= -march=k6
 # Please note, that patches that add -march=athlon-xp and friends are pointless.
 # They make zero difference whatsosever to performance at this time.
 cflags-$(CONFIG_MK7)		+= -march=athlon
-cflags-$(CONFIG_MK8)		+= $(call cc-option,-march=k8,-march=athlon)
 cflags-$(CONFIG_MCRUSOE)	+= -march=i686 $(align)
 cflags-$(CONFIG_MEFFICEON)	+= -march=i686 $(call tune,pentium3) $(align)
 cflags-$(CONFIG_MWINCHIPC6)	+= $(call cc-option,-march=winchip-c6,-march=i586)
@@ -32,9 +31,7 @@ cflags-$(CONFIG_MWINCHIP3D)	+= $(call cc-option,-march=winchip2,-march=i586)
 cflags-$(CONFIG_MCYRIXIII)	+= $(call cc-option,-march=c3,-march=i486) $(align)
 cflags-$(CONFIG_MVIAC3_2)	+= $(call cc-option,-march=c3-2,-march=i686)
 cflags-$(CONFIG_MVIAC7)		+= -march=i686
-cflags-$(CONFIG_MCORE2)		+= -march=i686 $(call tune,core2)
-cflags-$(CONFIG_MATOM)		+= $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \
-	$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))
+cflags-$(CONFIG_MATOM)		+= -march=atom
 
 # AMD Elan support
 cflags-$(CONFIG_MELAN)		+= -march=i486
diff --git a/arch/x86/include/asm/vermagic.h b/arch/x86/include/asm/vermagic.h
index 75884d2cdec3..5d471253c755 100644
--- a/arch/x86/include/asm/vermagic.h
+++ b/arch/x86/include/asm/vermagic.h
@@ -15,8 +15,6 @@
 #define MODULE_PROC_FAMILY "586TSC "
 #elif defined CONFIG_M586MMX
 #define MODULE_PROC_FAMILY "586MMX "
-#elif defined CONFIG_MCORE2
-#define MODULE_PROC_FAMILY "CORE2 "
 #elif defined CONFIG_MATOM
 #define MODULE_PROC_FAMILY "ATOM "
 #elif defined CONFIG_M686
@@ -33,8 +31,6 @@
 #define MODULE_PROC_FAMILY "K6 "
 #elif defined CONFIG_MK7
 #define MODULE_PROC_FAMILY "K7 "
-#elif defined CONFIG_MK8
-#define MODULE_PROC_FAMILY "K8 "
 #elif defined CONFIG_MELAN
 #define MODULE_PROC_FAMILY "ELAN "
 #elif defined CONFIG_MCRUSOE
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 67d9391f1855..7575fee96cc6 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -3,7 +3,7 @@
 config INTEL_MEI
 	tristate "Intel Management Engine Interface"
 	depends on X86 && PCI
-	default GENERIC_CPU || MCORE2 || MATOM || X86_GENERIC
+	default X86_64 || MATOM
 	help
 	  The Intel Management Engine (Intel ME) provides Manageability,
 	  Security and Media services for system containing Intel chipsets.
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/cpu: Drop configuration options for early 64-bit CPUs
  2025-02-26 21:37 ` [PATCH v3 04/10] x86: drop configuration options for early 64-bit CPUs Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     f388f60ca9041a95c9b3f157d316ed7c8f297e44
Gitweb:        https://git.kernel.org/tip/f388f60ca9041a95c9b3f157d316ed7c8f297e44
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:08 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:19:06 +01:00

x86/cpu: Drop configuration options for early 64-bit CPUs

The x86 CPU selection menu is confusing for a number of reasons:

When configuring 32-bit kernels, it shows a small number of early 64-bit
microarchitectures (K8, Core 2) but not the regular generic 64-bit target
that is the normal default.  There is no longer a reason to run 32-bit
kernels on production 64-bit systems, so only actual 32-bit CPUs need
to be shown here.

When configuring 64-bit kernels, the options also pointless as there is
no way to pick any CPU from the past 15 years, leaving GENERIC_CPU as
the only sensible choice.

Address both of the above by removing the obsolete options and making
all 64-bit kernels run on both Intel and AMD CPUs from any generation.
Testing generic 32-bit kernels on 64-bit hardware remains possible,
just not building a 32-bit kernel that requires a 64-bit CPU.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-5-arnd@kernel.org
---
 arch/x86/Kconfig.cpu            | 95 ++++----------------------------
 arch/x86/Makefile               | 16 +-----
 arch/x86/Makefile_32.cpu        |  5 +--
 arch/x86/include/asm/vermagic.h |  4 +-
 drivers/misc/mei/Kconfig        |  2 +-
 5 files changed, 18 insertions(+), 104 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 42e6a40..8fcb8cc 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -1,9 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 # Put here option for CPU selection and depending optimization
 choice
-	prompt "Processor family"
-	default M686 if X86_32
-	default GENERIC_CPU if X86_64
+	prompt "x86-32 Processor family"
+	depends on X86_32
+	default M686
 	help
 	  This is the processor type of your CPU. This information is
 	  used for optimizing purposes. In order to compile a kernel
@@ -31,7 +31,6 @@ choice
 	  - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
 	  - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
 	  - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
-	  - "Opteron/Athlon64/Hammer/K8" for all K8 and newer AMD CPUs.
 	  - "Crusoe" for the Transmeta Crusoe series.
 	  - "Efficeon" for the Transmeta Efficeon series.
 	  - "Winchip-C6" for original IDT Winchip.
@@ -42,13 +41,10 @@ choice
 	  - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
 	  - "VIA C3-2" for VIA C3-2 "Nehemiah" (model 9 and above).
 	  - "VIA C7" for VIA C7.
-	  - "Intel P4" for the Pentium 4/Netburst microarchitecture.
-	  - "Core 2/newer Xeon" for all core2 and newer Intel CPUs.
 	  - "Intel Atom" for the Atom-microarchitecture CPUs.
-	  - "Generic-x86-64" for a kernel which runs on any x86-64 CPU.
 
 	  See each option's help text for additional details. If you don't know
-	  what to do, choose "486".
+	  what to do, choose "Pentium-Pro".
 
 config M486SX
 	bool "486SX"
@@ -114,11 +110,11 @@ config MPENTIUMIII
 	  extensions.
 
 config MPENTIUMM
-	bool "Pentium M"
+	bool "Pentium M/Pentium Dual Core/Core Solo/Core Duo"
 	depends on X86_32
 	help
 	  Select this for Intel Pentium M (not Pentium-4 M)
-	  notebook chips.
+	  "Merom" Core Solo/Duo notebook chips
 
 config MPENTIUM4
 	bool "Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon"
@@ -139,22 +135,10 @@ config MPENTIUM4
 		-Mobile Pentium 4
 		-Mobile Pentium 4 M
 		-Extreme Edition (Gallatin)
-		-Prescott
-		-Prescott 2M
-		-Cedar Mill
-		-Presler
-		-Smithfiled
 	    Xeons (Intel Xeon, Xeon MP, Xeon LV, Xeon MV) corename:
 		-Foster
 		-Prestonia
 		-Gallatin
-		-Nocona
-		-Irwindale
-		-Cranford
-		-Potomac
-		-Paxville
-		-Dempsey
-
 
 config MK6
 	bool "K6/K6-II/K6-III"
@@ -172,13 +156,6 @@ config MK7
 	  some extended instructions, and passes appropriate optimization
 	  flags to GCC.
 
-config MK8
-	bool "Opteron/Athlon64/Hammer/K8"
-	help
-	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.
-	  Enables use of some extended instructions, and passes appropriate
-	  optimization flags to GCC.
-
 config MCRUSOE
 	bool "Crusoe"
 	depends on X86_32
@@ -258,42 +235,14 @@ config MVIAC7
 	  Select this for a VIA C7.  Selecting this uses the correct cache
 	  shift and tells gcc to treat the CPU as a 686.
 
-config MPSC
-	bool "Intel P4 / older Netburst based Xeon"
-	depends on X86_64
-	help
-	  Optimize for Intel Pentium 4, Pentium D and older Nocona/Dempsey
-	  Xeon CPUs with Intel 64bit which is compatible with x86-64.
-	  Note that the latest Xeons (Xeon 51xx and 53xx) are not based on the
-	  Netburst core and shouldn't use this option. You can distinguish them
-	  using the cpu family field
-	  in /proc/cpuinfo. Family 15 is an older Xeon, Family 6 a newer one.
-
-config MCORE2
-	bool "Core 2/newer Xeon"
-	help
-
-	  Select this for Intel Core 2 and newer Core 2 Xeons (Xeon 51xx and
-	  53xx) CPUs. You can distinguish newer from older Xeons by the CPU
-	  family in /proc/cpuinfo. Newer ones have 6 and older ones 15
-	  (not a typo)
-
 config MATOM
 	bool "Intel Atom"
 	help
-
 	  Select this for the Intel Atom platform. Intel Atom CPUs have an
 	  in-order pipelining architecture and thus can benefit from
 	  accordingly optimized code. Use a recent GCC with specific Atom
 	  support in order to fully benefit from selecting this option.
 
-config GENERIC_CPU
-	bool "Generic-x86-64"
-	depends on X86_64
-	help
-	  Generic x86-64 CPU.
-	  Run equally well on all x86-64 CPUs.
-
 endchoice
 
 config X86_GENERIC
@@ -317,8 +266,8 @@ config X86_INTERNODE_CACHE_SHIFT
 
 config X86_L1_CACHE_SHIFT
 	int
-	default "7" if MPENTIUM4 || MPSC
-	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU
+	default "7" if MPENTIUM4
+	default "6" if MK7 || MPENTIUMM || MATOM || MVIAC7 || X86_GENERIC || X86_64
 	default "4" if MELAN || M486SX || M486 || MGEODEGX1
 	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
 
@@ -336,35 +285,19 @@ config X86_ALIGNMENT_16
 
 config X86_INTEL_USERCOPY
 	def_bool y
-	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MCORE2
+	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK7 || MEFFICEON
 
 config X86_USE_PPRO_CHECKSUM
 	def_bool y
-	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM
-
-#
-# P6_NOPs are a relatively minor optimization that require a family >=
-# 6 processor, except that it is broken on certain VIA chips.
-# Furthermore, AMD chips prefer a totally different sequence of NOPs
-# (which work on all CPUs).  In addition, it looks like Virtual PC
-# does not understand them.
-#
-# As a result, disallow these if we're not compiling for X86_64 (these
-# NOPs do work on all x86-64 capable chips); the list of processors in
-# the right-hand clause are the cores that benefit from this optimization.
-#
-config X86_P6_NOP
-	def_bool y
-	depends on X86_64
-	depends on (MCORE2 || MPENTIUM4 || MPSC)
+	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MATOM
 
 config X86_TSC
 	def_bool y
-	depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2 || MATOM) || X86_64
+	depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MATOM) || X86_64
 
 config X86_HAVE_PAE
 	def_bool y
-	depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC7 || MCORE2 || MATOM || X86_64
+	depends on MCRUSOE || MEFFICEON || MCYRIXIII || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC7 || MATOM || X86_64
 
 config X86_CMPXCHG64
 	def_bool y
@@ -374,12 +307,12 @@ config X86_CMPXCHG64
 # generates cmov.
 config X86_CMOV
 	def_bool y
-	depends on (MK8 || MK7 || MCORE2 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MCRUSOE || MEFFICEON || X86_64 || MATOM || MGEODE_LX)
+	depends on (MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MCRUSOE || MEFFICEON || MATOM || MGEODE_LX || X86_64)
 
 config X86_MINIMUM_CPU_FAMILY
 	int
 	default "64" if X86_64
-	default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCORE2 || MK7 || MK8)
+	default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MK7)
 	default "5" if X86_32 && X86_CMPXCHG64
 	default "4"
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5af3172..8120085 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -178,20 +178,8 @@ else
 	# Use -mskip-rax-setup if supported.
 	KBUILD_CFLAGS += $(call cc-option,-mskip-rax-setup)
 
-        # FIXME - should be integrated in Makefile.cpu (Makefile_32.cpu)
-        cflags-$(CONFIG_MK8)		+= -march=k8
-        cflags-$(CONFIG_MPSC)		+= -march=nocona
-        cflags-$(CONFIG_MCORE2)		+= -march=core2
-        cflags-$(CONFIG_MATOM)		+= -march=atom
-        cflags-$(CONFIG_GENERIC_CPU)	+= -march=x86-64 -mtune=generic
-        KBUILD_CFLAGS += $(cflags-y)
-
-        rustflags-$(CONFIG_MK8)		+= -Ctarget-cpu=k8
-        rustflags-$(CONFIG_MPSC)	+= -Ctarget-cpu=nocona
-        rustflags-$(CONFIG_MCORE2)	+= -Ctarget-cpu=core2
-        rustflags-$(CONFIG_MATOM)	+= -Ctarget-cpu=atom
-        rustflags-$(CONFIG_GENERIC_CPU)	+= -Ctarget-cpu=x86-64 -Ztune-cpu=generic
-        KBUILD_RUSTFLAGS += $(rustflags-y)
+        KBUILD_CFLAGS += -march=x86-64 -mtune=generic
+        KBUILD_RUSTFLAGS += -Ctarget-cpu=x86-64 -Ztune-cpu=generic
 
         KBUILD_CFLAGS += -mno-red-zone
         KBUILD_CFLAGS += -mcmodel=kernel
diff --git a/arch/x86/Makefile_32.cpu b/arch/x86/Makefile_32.cpu
index 94834c4..af7de9a 100644
--- a/arch/x86/Makefile_32.cpu
+++ b/arch/x86/Makefile_32.cpu
@@ -24,7 +24,6 @@ cflags-$(CONFIG_MK6)		+= -march=k6
 # Please note, that patches that add -march=athlon-xp and friends are pointless.
 # They make zero difference whatsosever to performance at this time.
 cflags-$(CONFIG_MK7)		+= -march=athlon
-cflags-$(CONFIG_MK8)		+= $(call cc-option,-march=k8,-march=athlon)
 cflags-$(CONFIG_MCRUSOE)	+= -march=i686 $(align)
 cflags-$(CONFIG_MEFFICEON)	+= -march=i686 $(call tune,pentium3) $(align)
 cflags-$(CONFIG_MWINCHIPC6)	+= $(call cc-option,-march=winchip-c6,-march=i586)
@@ -32,9 +31,7 @@ cflags-$(CONFIG_MWINCHIP3D)	+= $(call cc-option,-march=winchip2,-march=i586)
 cflags-$(CONFIG_MCYRIXIII)	+= $(call cc-option,-march=c3,-march=i486) $(align)
 cflags-$(CONFIG_MVIAC3_2)	+= $(call cc-option,-march=c3-2,-march=i686)
 cflags-$(CONFIG_MVIAC7)		+= -march=i686
-cflags-$(CONFIG_MCORE2)		+= -march=i686 $(call tune,core2)
-cflags-$(CONFIG_MATOM)		+= $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \
-	$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))
+cflags-$(CONFIG_MATOM)		+= -march=atom
 
 # AMD Elan support
 cflags-$(CONFIG_MELAN)		+= -march=i486
diff --git a/arch/x86/include/asm/vermagic.h b/arch/x86/include/asm/vermagic.h
index 75884d2..5d47125 100644
--- a/arch/x86/include/asm/vermagic.h
+++ b/arch/x86/include/asm/vermagic.h
@@ -15,8 +15,6 @@
 #define MODULE_PROC_FAMILY "586TSC "
 #elif defined CONFIG_M586MMX
 #define MODULE_PROC_FAMILY "586MMX "
-#elif defined CONFIG_MCORE2
-#define MODULE_PROC_FAMILY "CORE2 "
 #elif defined CONFIG_MATOM
 #define MODULE_PROC_FAMILY "ATOM "
 #elif defined CONFIG_M686
@@ -33,8 +31,6 @@
 #define MODULE_PROC_FAMILY "K6 "
 #elif defined CONFIG_MK7
 #define MODULE_PROC_FAMILY "K7 "
-#elif defined CONFIG_MK8
-#define MODULE_PROC_FAMILY "K8 "
 #elif defined CONFIG_MELAN
 #define MODULE_PROC_FAMILY "ELAN "
 #elif defined CONFIG_MCRUSOE
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 67d9391..7575fee 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -3,7 +3,7 @@
 config INTEL_MEI
 	tristate "Intel Management Engine Interface"
 	depends on X86 && PCI
-	default GENERIC_CPU || MCORE2 || MATOM || X86_GENERIC
+	default X86_64 || MATOM
 	help
 	  The Intel Management Engine (Intel ME) provides Manageability,
 	  Security and Media services for system containing Intel chipsets.

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 05/10] x86: remove HIGHMEM64G support
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (3 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 04/10] x86: drop configuration options for early 64-bit CPUs Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Remove CONFIG_HIGHMEM64G support tip-bot2 for Arnd Bergmann
  2025-02-27 15:41   ` [PATCH v3 05/10] x86: remove HIGHMEM64G support H. Peter Anvin
  2025-02-26 21:37 ` [PATCH v3 06/10] x86: drop SWIOTLB for PAE Arnd Bergmann
                   ` (5 subsequent siblings)
  10 siblings, 2 replies; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

The HIGHMEM64G support was added in linux-2.3.25 to support (then)
high-end Pentium Pro and Pentium III Xeon servers with more than 4GB of
addressing, NUMA and PCI-X slots started appearing.

I have found no evidence of this ever being used in regular dual-socket
servers or consumer devices, all the users seem obsolete these days,
even by i386 standards:

 - Support for NUMA servers (NUMA-Q, IBM x440, unisys) was already
   removed ten years ago.

 - 4+ socket non-NUMA servers based on Intel 450GX/450NX, HP F8 and
   ServerWorks ServerSet/GrandChampion could theoretically still work
   with 8GB, but these were exceptionally rare even 20 years ago and
   would have usually been equipped with than the maximum amount of
   RAM.

 - Some SKUs of the Celeron D from 2004 had 64-bit mode fused off but
   could still work in a Socket 775 mainboard designed for the later
   Core 2 Duo and 8GB. Apparently most BIOSes at the time only allowed
   64-bit CPUs.

 - The rare Xeon LV "Sossaman" came on a few motherboards with
   registered DDR2 memory support up to 16GB.

 - In the early days of x86-64 hardware, there was sometimes the need
   to run a 32-bit kernel to work around bugs in the hardware drivers,
   or in the syscall emulation for 32-bit userspace. This likely still
   works but there should never be a need for this any more.

PAE mode is still required to get access to the 'NX' bit on Atom
'Pentium M' and 'Core Duo' CPUs.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 Documentation/admin-guide/kdump/kdump.rst     |  4 --
 Documentation/arch/x86/usb-legacy-support.rst | 11 +----
 arch/x86/Kconfig                              | 46 +++----------------
 arch/x86/configs/xen.config                   |  2 -
 arch/x86/include/asm/page_32_types.h          |  4 +-
 arch/x86/mm/init_32.c                         |  9 +---
 6 files changed, 11 insertions(+), 65 deletions(-)

diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index 5376890adbeb..1f7f14c6e184 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
 1) On i386, enable high memory support under "Processor type and
    features"::
 
-	CONFIG_HIGHMEM64G=y
-
-   or::
-
 	CONFIG_HIGHMEM4G
 
 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
diff --git a/Documentation/arch/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst
index e01c08b7c981..b17bf122270a 100644
--- a/Documentation/arch/x86/usb-legacy-support.rst
+++ b/Documentation/arch/x86/usb-legacy-support.rst
@@ -20,11 +20,7 @@ It has several drawbacks, though:
    features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may
    not be available.
 
-2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause
-   system crashes, because the SMM BIOS is not expecting to be in PAE mode.
-   The Intel E7505 is a typical machine where this happens.
-
-3) If AMD64 64-bit mode is enabled, again system crashes often happen,
+2) If AMD64 64-bit mode is enabled, again system crashes often happen,
    because the SMM BIOS isn't expecting the CPU to be in 64-bit mode.  The
    BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit
    yet.
@@ -38,11 +34,6 @@ Problem 1)
   compiled-in, too.
 
 Problem 2)
-  can currently only be solved by either disabling HIGHMEM64G
-  in the kernel config or USB Legacy support in the BIOS. A BIOS update
-  could help, but so far no such update exists.
-
-Problem 3)
   is usually fixed by a BIOS update. Check the board
   manufacturers web site. If an update is not available, disable USB
   Legacy support in the BIOS. If this alone doesn't help, try also adding
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4a1205b22ae2..d785cb368125 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1387,15 +1387,11 @@ config X86_CPUID
 	  with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
 	  /dev/cpu/31/cpuid.
 
-choice
-	prompt "High Memory Support"
-	default HIGHMEM4G
+config HIGHMEM4G
+	bool "High Memory Support"
 	depends on X86_32
-
-config NOHIGHMEM
-	bool "off"
 	help
-	  Linux can use up to 64 Gigabytes of physical memory on x86 systems.
+	  Linux can use up to 4 Gigabytes of physical memory on x86 systems.
 	  However, the address space of 32-bit x86 processors is only 4
 	  Gigabytes large. That means that, if you have a large amount of
 	  physical memory, not all of it can be "permanently mapped" by the
@@ -1411,38 +1407,9 @@ config NOHIGHMEM
 	  possible.
 
 	  If the machine has between 1 and 4 Gigabytes physical RAM, then
-	  answer "4GB" here.
+	  answer "Y" here.
 
-	  If more than 4 Gigabytes is used then answer "64GB" here. This
-	  selection turns Intel PAE (Physical Address Extension) mode on.
-	  PAE implements 3-level paging on IA32 processors. PAE is fully
-	  supported by Linux, PAE mode is implemented on all recent Intel
-	  processors (Pentium Pro and better). NOTE: If you say "64GB" here,
-	  then the kernel will not boot on CPUs that don't support PAE!
-
-	  The actual amount of total physical memory will either be
-	  auto detected or can be forced by using a kernel command line option
-	  such as "mem=256M". (Try "man bootparam" or see the documentation of
-	  your boot loader (lilo or loadlin) about how to pass options to the
-	  kernel at boot time.)
-
-	  If unsure, say "off".
-
-config HIGHMEM4G
-	bool "4GB"
-	help
-	  Select this if you have a 32-bit processor and between 1 and 4
-	  gigabytes of physical RAM.
-
-config HIGHMEM64G
-	bool "64GB"
-	depends on X86_HAVE_PAE
-	select X86_PAE
-	help
-	  Select this if you have a 32-bit processor and more than 4
-	  gigabytes of physical RAM.
-
-endchoice
+	  If unsure, say N.
 
 choice
 	prompt "Memory split" if EXPERT
@@ -1488,8 +1455,7 @@ config PAGE_OFFSET
 	depends on X86_32
 
 config HIGHMEM
-	def_bool y
-	depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
+	def_bool HIGHMEM4G
 
 config X86_PAE
 	bool "PAE (Physical Address Extension) Support"
diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
index 581296255b39..d5d091e03bd3 100644
--- a/arch/x86/configs/xen.config
+++ b/arch/x86/configs/xen.config
@@ -1,6 +1,4 @@
 # global x86 required specific stuff
-# On 32-bit HIGHMEM4G is not allowed
-CONFIG_HIGHMEM64G=y
 CONFIG_64BIT=y
 
 # These enable us to allow some of the
diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
index faf9cc1c14bb..25c32652f404 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -11,8 +11,8 @@
  * a virtual address space of one gigabyte, which limits the
  * amount of physical memory you can use to about 950MB.
  *
- * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
- * and CONFIG_HIGHMEM64G options in the kernel configuration.
+ * If you want more physical memory than this then see the CONFIG_VMSPLIT_2G
+ * and CONFIG_HIGHMEM4G options in the kernel configuration.
  */
 #define __PAGE_OFFSET_BASE	_AC(CONFIG_PAGE_OFFSET, UL)
 #define __PAGE_OFFSET		__PAGE_OFFSET_BASE
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index ac41b1e0940d..f288aad8dc74 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -582,7 +582,7 @@ static void __init lowmem_pfn_init(void)
 	"only %luMB highmem pages available, ignoring highmem size of %luMB!\n"
 
 #define MSG_HIGHMEM_TRIMMED \
-	"Warning: only 4GB will be used. Use a HIGHMEM64G enabled kernel!\n"
+	"Warning: only 4GB will be used. Support for for CONFIG_HIGHMEM64G was removed!\n"
 /*
  * We have more RAM than fits into lowmem - we try to put it into
  * highmem, also taking the highmem=x boot parameter into account:
@@ -606,18 +606,13 @@ static void __init highmem_pfn_init(void)
 #ifndef CONFIG_HIGHMEM
 	/* Maximum memory usable is what is directly addressable */
 	printk(KERN_WARNING "Warning only %ldMB will be used.\n", MAXMEM>>20);
-	if (max_pfn > MAX_NONPAE_PFN)
-		printk(KERN_WARNING "Use a HIGHMEM64G enabled kernel.\n");
-	else
-		printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
+	printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
 	max_pfn = MAXMEM_PFN;
 #else /* !CONFIG_HIGHMEM */
-#ifndef CONFIG_HIGHMEM64G
 	if (max_pfn > MAX_NONPAE_PFN) {
 		max_pfn = MAX_NONPAE_PFN;
 		printk(KERN_WARNING MSG_HIGHMEM_TRIMMED);
 	}
-#endif /* !CONFIG_HIGHMEM64G */
 #endif /* !CONFIG_HIGHMEM */
 }
 
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/mm: Remove CONFIG_HIGHMEM64G support
  2025-02-26 21:37 ` [PATCH v3 05/10] x86: remove HIGHMEM64G support Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  2025-02-27 15:41   ` [PATCH v3 05/10] x86: remove HIGHMEM64G support H. Peter Anvin
  1 sibling, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     bbeb69ce301323e84f1677484eb8e4cd8fb1f9f8
Gitweb:        https://git.kernel.org/tip/bbeb69ce301323e84f1677484eb8e4cd8fb1f9f8
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:09 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:21:53 +01:00

x86/mm: Remove CONFIG_HIGHMEM64G support

HIGHMEM64G support was added in linux-2.3.25 to support (then)
high-end Pentium Pro and Pentium III Xeon servers with more than 4GB of
addressing, NUMA and PCI-X slots started appearing.

I have found no evidence of this ever being used in regular dual-socket
servers or consumer devices, all the users seem obsolete these days,
even by i386 standards:

 - Support for NUMA servers (NUMA-Q, IBM x440, unisys) was already
   removed ten years ago.

 - 4+ socket non-NUMA servers based on Intel 450GX/450NX, HP F8 and
   ServerWorks ServerSet/GrandChampion could theoretically still work
   with 8GB, but these were exceptionally rare even 20 years ago and
   would have usually been equipped with than the maximum amount of
   RAM.

 - Some SKUs of the Celeron D from 2004 had 64-bit mode fused off but
   could still work in a Socket 775 mainboard designed for the later
   Core 2 Duo and 8GB. Apparently most BIOSes at the time only allowed
   64-bit CPUs.

 - The rare Xeon LV "Sossaman" came on a few motherboards with
   registered DDR2 memory support up to 16GB.

 - In the early days of x86-64 hardware, there was sometimes the need
   to run a 32-bit kernel to work around bugs in the hardware drivers,
   or in the syscall emulation for 32-bit userspace. This likely still
   works but there should never be a need for this any more.

PAE mode is still required to get access to the 'NX' bit on Atom
'Pentium M' and 'Core Duo' CPUs.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-6-arnd@kernel.org
---
 Documentation/admin-guide/kdump/kdump.rst     |  4 +--
 Documentation/arch/x86/usb-legacy-support.rst | 11 +----
 arch/x86/Kconfig                              | 46 ++----------------
 arch/x86/configs/xen.config                   |  2 +-
 arch/x86/include/asm/page_32_types.h          |  4 +-
 arch/x86/mm/init_32.c                         |  9 +----
 6 files changed, 11 insertions(+), 65 deletions(-)

diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index 5376890..1f7f14c 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
 1) On i386, enable high memory support under "Processor type and
    features"::
 
-	CONFIG_HIGHMEM64G=y
-
-   or::
-
 	CONFIG_HIGHMEM4G
 
 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
diff --git a/Documentation/arch/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst
index e01c08b..b17bf12 100644
--- a/Documentation/arch/x86/usb-legacy-support.rst
+++ b/Documentation/arch/x86/usb-legacy-support.rst
@@ -20,11 +20,7 @@ It has several drawbacks, though:
    features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may
    not be available.
 
-2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause
-   system crashes, because the SMM BIOS is not expecting to be in PAE mode.
-   The Intel E7505 is a typical machine where this happens.
-
-3) If AMD64 64-bit mode is enabled, again system crashes often happen,
+2) If AMD64 64-bit mode is enabled, again system crashes often happen,
    because the SMM BIOS isn't expecting the CPU to be in 64-bit mode.  The
    BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit
    yet.
@@ -38,11 +34,6 @@ Problem 1)
   compiled-in, too.
 
 Problem 2)
-  can currently only be solved by either disabling HIGHMEM64G
-  in the kernel config or USB Legacy support in the BIOS. A BIOS update
-  could help, but so far no such update exists.
-
-Problem 3)
   is usually fixed by a BIOS update. Check the board
   manufacturers web site. If an update is not available, disable USB
   Legacy support in the BIOS. If this alone doesn't help, try also adding
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 887b77b..737a0c6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1388,15 +1388,11 @@ config X86_CPUID
 	  with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
 	  /dev/cpu/31/cpuid.
 
-choice
-	prompt "High Memory Support"
-	default HIGHMEM4G
+config HIGHMEM4G
+	bool "High Memory Support"
 	depends on X86_32
-
-config NOHIGHMEM
-	bool "off"
 	help
-	  Linux can use up to 64 Gigabytes of physical memory on x86 systems.
+	  Linux can use up to 4 Gigabytes of physical memory on x86 systems.
 	  However, the address space of 32-bit x86 processors is only 4
 	  Gigabytes large. That means that, if you have a large amount of
 	  physical memory, not all of it can be "permanently mapped" by the
@@ -1412,38 +1408,9 @@ config NOHIGHMEM
 	  possible.
 
 	  If the machine has between 1 and 4 Gigabytes physical RAM, then
-	  answer "4GB" here.
+	  answer "Y" here.
 
-	  If more than 4 Gigabytes is used then answer "64GB" here. This
-	  selection turns Intel PAE (Physical Address Extension) mode on.
-	  PAE implements 3-level paging on IA32 processors. PAE is fully
-	  supported by Linux, PAE mode is implemented on all recent Intel
-	  processors (Pentium Pro and better). NOTE: If you say "64GB" here,
-	  then the kernel will not boot on CPUs that don't support PAE!
-
-	  The actual amount of total physical memory will either be
-	  auto detected or can be forced by using a kernel command line option
-	  such as "mem=256M". (Try "man bootparam" or see the documentation of
-	  your boot loader (lilo or loadlin) about how to pass options to the
-	  kernel at boot time.)
-
-	  If unsure, say "off".
-
-config HIGHMEM4G
-	bool "4GB"
-	help
-	  Select this if you have a 32-bit processor and between 1 and 4
-	  gigabytes of physical RAM.
-
-config HIGHMEM64G
-	bool "64GB"
-	depends on X86_HAVE_PAE
-	select X86_PAE
-	help
-	  Select this if you have a 32-bit processor and more than 4
-	  gigabytes of physical RAM.
-
-endchoice
+	  If unsure, say N.
 
 choice
 	prompt "Memory split" if EXPERT
@@ -1489,8 +1456,7 @@ config PAGE_OFFSET
 	depends on X86_32
 
 config HIGHMEM
-	def_bool y
-	depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
+	def_bool HIGHMEM4G
 
 config X86_PAE
 	bool "PAE (Physical Address Extension) Support"
diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
index 5812962..d5d091e 100644
--- a/arch/x86/configs/xen.config
+++ b/arch/x86/configs/xen.config
@@ -1,6 +1,4 @@
 # global x86 required specific stuff
-# On 32-bit HIGHMEM4G is not allowed
-CONFIG_HIGHMEM64G=y
 CONFIG_64BIT=y
 
 # These enable us to allow some of the
diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
index faf9cc1..25c3265 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -11,8 +11,8 @@
  * a virtual address space of one gigabyte, which limits the
  * amount of physical memory you can use to about 950MB.
  *
- * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
- * and CONFIG_HIGHMEM64G options in the kernel configuration.
+ * If you want more physical memory than this then see the CONFIG_VMSPLIT_2G
+ * and CONFIG_HIGHMEM4G options in the kernel configuration.
  */
 #define __PAGE_OFFSET_BASE	_AC(CONFIG_PAGE_OFFSET, UL)
 #define __PAGE_OFFSET		__PAGE_OFFSET_BASE
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index ac41b1e..f288aad 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -582,7 +582,7 @@ static void __init lowmem_pfn_init(void)
 	"only %luMB highmem pages available, ignoring highmem size of %luMB!\n"
 
 #define MSG_HIGHMEM_TRIMMED \
-	"Warning: only 4GB will be used. Use a HIGHMEM64G enabled kernel!\n"
+	"Warning: only 4GB will be used. Support for for CONFIG_HIGHMEM64G was removed!\n"
 /*
  * We have more RAM than fits into lowmem - we try to put it into
  * highmem, also taking the highmem=x boot parameter into account:
@@ -606,18 +606,13 @@ static void __init highmem_pfn_init(void)
 #ifndef CONFIG_HIGHMEM
 	/* Maximum memory usable is what is directly addressable */
 	printk(KERN_WARNING "Warning only %ldMB will be used.\n", MAXMEM>>20);
-	if (max_pfn > MAX_NONPAE_PFN)
-		printk(KERN_WARNING "Use a HIGHMEM64G enabled kernel.\n");
-	else
-		printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
+	printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
 	max_pfn = MAXMEM_PFN;
 #else /* !CONFIG_HIGHMEM */
-#ifndef CONFIG_HIGHMEM64G
 	if (max_pfn > MAX_NONPAE_PFN) {
 		max_pfn = MAX_NONPAE_PFN;
 		printk(KERN_WARNING MSG_HIGHMEM_TRIMMED);
 	}
-#endif /* !CONFIG_HIGHMEM64G */
 #endif /* !CONFIG_HIGHMEM */
 }
 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support
  2025-02-26 21:37 ` [PATCH v3 05/10] x86: remove HIGHMEM64G support Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Remove CONFIG_HIGHMEM64G support tip-bot2 for Arnd Bergmann
@ 2025-02-27 15:41   ` H. Peter Anvin
  2025-02-27 16:51     ` Linus Torvalds
  1 sibling, 1 reply; 29+ messages in thread
From: H. Peter Anvin @ 2025-02-27 15:41 UTC (permalink / raw)
  To: Arnd Bergmann, linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, Linus Torvalds, Andy Shevchenko, Matthew Wilcox

On February 26, 2025 1:37:09 PM PST, Arnd Bergmann <arnd@kernel.org> wrote:
>From: Arnd Bergmann <arnd@arndb.de>
>
>The HIGHMEM64G support was added in linux-2.3.25 to support (then)
>high-end Pentium Pro and Pentium III Xeon servers with more than 4GB of
>addressing, NUMA and PCI-X slots started appearing.
>
>I have found no evidence of this ever being used in regular dual-socket
>servers or consumer devices, all the users seem obsolete these days,
>even by i386 standards:
>
> - Support for NUMA servers (NUMA-Q, IBM x440, unisys) was already
>   removed ten years ago.
>
> - 4+ socket non-NUMA servers based on Intel 450GX/450NX, HP F8 and
>   ServerWorks ServerSet/GrandChampion could theoretically still work
>   with 8GB, but these were exceptionally rare even 20 years ago and
>   would have usually been equipped with than the maximum amount of
>   RAM.
>
> - Some SKUs of the Celeron D from 2004 had 64-bit mode fused off but
>   could still work in a Socket 775 mainboard designed for the later
>   Core 2 Duo and 8GB. Apparently most BIOSes at the time only allowed
>   64-bit CPUs.
>
> - The rare Xeon LV "Sossaman" came on a few motherboards with
>   registered DDR2 memory support up to 16GB.
>
> - In the early days of x86-64 hardware, there was sometimes the need
>   to run a 32-bit kernel to work around bugs in the hardware drivers,
>   or in the syscall emulation for 32-bit userspace. This likely still
>   works but there should never be a need for this any more.
>
>PAE mode is still required to get access to the 'NX' bit on Atom
>'Pentium M' and 'Core Duo' CPUs.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>---
> Documentation/admin-guide/kdump/kdump.rst     |  4 --
> Documentation/arch/x86/usb-legacy-support.rst | 11 +----
> arch/x86/Kconfig                              | 46 +++----------------
> arch/x86/configs/xen.config                   |  2 -
> arch/x86/include/asm/page_32_types.h          |  4 +-
> arch/x86/mm/init_32.c                         |  9 +---
> 6 files changed, 11 insertions(+), 65 deletions(-)
>
>diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
>index 5376890adbeb..1f7f14c6e184 100644
>--- a/Documentation/admin-guide/kdump/kdump.rst
>+++ b/Documentation/admin-guide/kdump/kdump.rst
>@@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
> 1) On i386, enable high memory support under "Processor type and
>    features"::
> 
>-	CONFIG_HIGHMEM64G=y
>-
>-   or::
>-
> 	CONFIG_HIGHMEM4G
> 
> 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
>diff --git a/Documentation/arch/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst
>index e01c08b7c981..b17bf122270a 100644
>--- a/Documentation/arch/x86/usb-legacy-support.rst
>+++ b/Documentation/arch/x86/usb-legacy-support.rst
>@@ -20,11 +20,7 @@ It has several drawbacks, though:
>    features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may
>    not be available.
> 
>-2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause
>-   system crashes, because the SMM BIOS is not expecting to be in PAE mode.
>-   The Intel E7505 is a typical machine where this happens.
>-
>-3) If AMD64 64-bit mode is enabled, again system crashes often happen,
>+2) If AMD64 64-bit mode is enabled, again system crashes often happen,
>    because the SMM BIOS isn't expecting the CPU to be in 64-bit mode.  The
>    BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit
>    yet.
>@@ -38,11 +34,6 @@ Problem 1)
>   compiled-in, too.
> 
> Problem 2)
>-  can currently only be solved by either disabling HIGHMEM64G
>-  in the kernel config or USB Legacy support in the BIOS. A BIOS update
>-  could help, but so far no such update exists.
>-
>-Problem 3)
>   is usually fixed by a BIOS update. Check the board
>   manufacturers web site. If an update is not available, disable USB
>   Legacy support in the BIOS. If this alone doesn't help, try also adding
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 4a1205b22ae2..d785cb368125 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -1387,15 +1387,11 @@ config X86_CPUID
> 	  with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
> 	  /dev/cpu/31/cpuid.
> 
>-choice
>-	prompt "High Memory Support"
>-	default HIGHMEM4G
>+config HIGHMEM4G
>+	bool "High Memory Support"
> 	depends on X86_32
>-
>-config NOHIGHMEM
>-	bool "off"
> 	help
>-	  Linux can use up to 64 Gigabytes of physical memory on x86 systems.
>+	  Linux can use up to 4 Gigabytes of physical memory on x86 systems.
> 	  However, the address space of 32-bit x86 processors is only 4
> 	  Gigabytes large. That means that, if you have a large amount of
> 	  physical memory, not all of it can be "permanently mapped" by the
>@@ -1411,38 +1407,9 @@ config NOHIGHMEM
> 	  possible.
> 
> 	  If the machine has between 1 and 4 Gigabytes physical RAM, then
>-	  answer "4GB" here.
>+	  answer "Y" here.
> 
>-	  If more than 4 Gigabytes is used then answer "64GB" here. This
>-	  selection turns Intel PAE (Physical Address Extension) mode on.
>-	  PAE implements 3-level paging on IA32 processors. PAE is fully
>-	  supported by Linux, PAE mode is implemented on all recent Intel
>-	  processors (Pentium Pro and better). NOTE: If you say "64GB" here,
>-	  then the kernel will not boot on CPUs that don't support PAE!
>-
>-	  The actual amount of total physical memory will either be
>-	  auto detected or can be forced by using a kernel command line option
>-	  such as "mem=256M". (Try "man bootparam" or see the documentation of
>-	  your boot loader (lilo or loadlin) about how to pass options to the
>-	  kernel at boot time.)
>-
>-	  If unsure, say "off".
>-
>-config HIGHMEM4G
>-	bool "4GB"
>-	help
>-	  Select this if you have a 32-bit processor and between 1 and 4
>-	  gigabytes of physical RAM.
>-
>-config HIGHMEM64G
>-	bool "64GB"
>-	depends on X86_HAVE_PAE
>-	select X86_PAE
>-	help
>-	  Select this if you have a 32-bit processor and more than 4
>-	  gigabytes of physical RAM.
>-
>-endchoice
>+	  If unsure, say N.
> 
> choice
> 	prompt "Memory split" if EXPERT
>@@ -1488,8 +1455,7 @@ config PAGE_OFFSET
> 	depends on X86_32
> 
> config HIGHMEM
>-	def_bool y
>-	depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
>+	def_bool HIGHMEM4G
> 
> config X86_PAE
> 	bool "PAE (Physical Address Extension) Support"
>diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
>index 581296255b39..d5d091e03bd3 100644
>--- a/arch/x86/configs/xen.config
>+++ b/arch/x86/configs/xen.config
>@@ -1,6 +1,4 @@
> # global x86 required specific stuff
>-# On 32-bit HIGHMEM4G is not allowed
>-CONFIG_HIGHMEM64G=y
> CONFIG_64BIT=y
> 
> # These enable us to allow some of the
>diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
>index faf9cc1c14bb..25c32652f404 100644
>--- a/arch/x86/include/asm/page_32_types.h
>+++ b/arch/x86/include/asm/page_32_types.h
>@@ -11,8 +11,8 @@
>  * a virtual address space of one gigabyte, which limits the
>  * amount of physical memory you can use to about 950MB.
>  *
>- * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
>- * and CONFIG_HIGHMEM64G options in the kernel configuration.
>+ * If you want more physical memory than this then see the CONFIG_VMSPLIT_2G
>+ * and CONFIG_HIGHMEM4G options in the kernel configuration.
>  */
> #define __PAGE_OFFSET_BASE	_AC(CONFIG_PAGE_OFFSET, UL)
> #define __PAGE_OFFSET		__PAGE_OFFSET_BASE
>diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
>index ac41b1e0940d..f288aad8dc74 100644
>--- a/arch/x86/mm/init_32.c
>+++ b/arch/x86/mm/init_32.c
>@@ -582,7 +582,7 @@ static void __init lowmem_pfn_init(void)
> 	"only %luMB highmem pages available, ignoring highmem size of %luMB!\n"
> 
> #define MSG_HIGHMEM_TRIMMED \
>-	"Warning: only 4GB will be used. Use a HIGHMEM64G enabled kernel!\n"
>+	"Warning: only 4GB will be used. Support for for CONFIG_HIGHMEM64G was removed!\n"
> /*
>  * We have more RAM than fits into lowmem - we try to put it into
>  * highmem, also taking the highmem=x boot parameter into account:
>@@ -606,18 +606,13 @@ static void __init highmem_pfn_init(void)
> #ifndef CONFIG_HIGHMEM
> 	/* Maximum memory usable is what is directly addressable */
> 	printk(KERN_WARNING "Warning only %ldMB will be used.\n", MAXMEM>>20);
>-	if (max_pfn > MAX_NONPAE_PFN)
>-		printk(KERN_WARNING "Use a HIGHMEM64G enabled kernel.\n");
>-	else
>-		printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
>+	printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
> 	max_pfn = MAXMEM_PFN;
> #else /* !CONFIG_HIGHMEM */
>-#ifndef CONFIG_HIGHMEM64G
> 	if (max_pfn > MAX_NONPAE_PFN) {
> 		max_pfn = MAX_NONPAE_PFN;
> 		printk(KERN_WARNING MSG_HIGHMEM_TRIMMED);
> 	}
>-#endif /* !CONFIG_HIGHMEM64G */
> #endif /* !CONFIG_HIGHMEM */
> }
> 

One of the generations of kernel.org ran on a dual socket system with 6 GiB RAM. It was a mess; basically it achieved less than 50% memory utilization because of highmem.

The next generation after that was 64 bits  hardware and software.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support
  2025-02-27 15:41   ` [PATCH v3 05/10] x86: remove HIGHMEM64G support H. Peter Anvin
@ 2025-02-27 16:51     ` Linus Torvalds
  2025-02-28  1:48       ` H. Peter Anvin
  2025-02-28 10:09       ` Arnd Bergmann
  0 siblings, 2 replies; 29+ messages in thread
From: Linus Torvalds @ 2025-02-27 16:51 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Arnd Bergmann, linux-kernel, x86, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, Andy Shevchenko,
	Matthew Wilcox

On Thu, 27 Feb 2025 at 07:41, H. Peter Anvin <hpa@zytor.com> wrote:
>
> One of the generations of kernel.org ran on a dual socket system with
> 6 GiB RAM. It was a mess; basically it achieved less than 50% memory
> utilization because of highmem.

I'll be very very happy when HIGHMEM is gone completely, but yes,
HIGHMEM64G was particularly painful.

It was definitely used, and it worked better under some loads than
others (large user footprints with lots of anonymous memory and little
kernel side memory pressure), but it was not great in general.

I suspect that absolutely everybody who ever used it switched to
64-bit as soon as humanly possible and nobody has likely actively used
it for a *long* time.

Good riddance,

            Linus

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support
  2025-02-27 16:51     ` Linus Torvalds
@ 2025-02-28  1:48       ` H. Peter Anvin
  2025-02-28 10:09       ` Arnd Bergmann
  1 sibling, 0 replies; 29+ messages in thread
From: H. Peter Anvin @ 2025-02-28  1:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Arnd Bergmann, linux-kernel, x86, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, Andy Shevchenko,
	Matthew Wilcox

On February 27, 2025 8:51:59 AM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Thu, 27 Feb 2025 at 07:41, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> One of the generations of kernel.org ran on a dual socket system with
>> 6 GiB RAM. It was a mess; basically it achieved less than 50% memory
>> utilization because of highmem.
>
>I'll be very very happy when HIGHMEM is gone completely, but yes,
>HIGHMEM64G was particularly painful.
>
>It was definitely used, and it worked better under some loads than
>others (large user footprints with lots of anonymous memory and little
>kernel side memory pressure), but it was not great in general.
>
>I suspect that absolutely everybody who ever used it switched to
>64-bit as soon as humanly possible and nobody has likely actively used
>it for a *long* time.
>
>Good riddance,
>
>            Linus

I wish that were true. 

At rPath I had to debug a customer machine where they insisted on a 32-bit OS because they were worried about the breakage possibilities of the compat layer. In retrospect we really didn't spend enough time/effort on making sure an all-32-bit userspace would run on a 64-bit kernel; little corner cases like autofs (my fault) that only popped up when all the system software was 32 bits...

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support
  2025-02-27 16:51     ` Linus Torvalds
  2025-02-28  1:48       ` H. Peter Anvin
@ 2025-02-28 10:09       ` Arnd Bergmann
  1 sibling, 0 replies; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-28 10:09 UTC (permalink / raw)
  To: Linus Torvalds, H. Peter Anvin
  Cc: Arnd Bergmann, linux-kernel, x86, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, Andy Shevchenko, Matthew Wilcox,
	linux-mm

On Thu, Feb 27, 2025, at 17:51, Linus Torvalds wrote:
> On Thu, 27 Feb 2025 at 07:41, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> One of the generations of kernel.org ran on a dual socket system with
>> 6 GiB RAM. It was a mess; basically it achieved less than 50% memory
>> utilization because of highmem.
>
> I'll be very very happy when HIGHMEM is gone completely, but yes,
> HIGHMEM64G was particularly painful.

I'm optimistic about being able to remove highmem in the future
as well, hopefully this series was a good step in that direction.

This is a rough list of what I think the remaining problems are:

- anyone running 32-bit kernels on 64-bit hardware or virtual
  machines should move to 64-bit kernels. This is mostly about
  educating users (on x86) and embedded system builders (on arm
  and possibly powerpc/booke64).
  One idea we had discussed in the past was to have the
  kernel refuse to run on 64-bit hardware if highmem is
  detected (with a command line override to allow regression
  testing).

- arm32 needs a way to have sparse physical memory linearized
  into lowmem, to deal with the case where the total memory is
  small enough to fit, but half of it sits at a high physical
  address. We are working on this.

- Ideally the same change should support a boot-time vmsplit
  selection on arm32 instead of compile-time CONFIG_VMSPLIT_*.
  This would also help x86-32 when a distro kernel needs to run
  on both 1GB and 2GB RAM machines but still allow
  3GB of user addresses on smaller machines.

- Machines with 3GB or 4GB of RAM (pre-2005 Intel PC/server
  systems, 2005-2007 era Intel Laptops, 2007-2009 era
  Netbooks, 2013-2015 era Arm Chromebooks, rare Arm/x86/PowerPC
  embedded systems) can hopefully get away with a combination
  of VMSPLIT_2G and zram/zswap.
  Someone needs to rework the highmem code to separate the
  bits needed for zsmalloc from the rest so we can disable
  and eventually remove normal highmem while keeping
  zsmalloc-in-highmem. I have not looked in detail at how
  that would work in practice.

- There is still an open question about implementing a
  4GB-split on ARM-LPAE (flipping a 3.75GB ttbr0 between
  lowmem and user). Linus Walleij has done some work on
  this, but we may find that VMSPLIT_2G plus zsmalloc-only
  highmem is good enough that we don't need both. Both
  approaches have important downsides.

- arm32 machines with more than 4GB of total memory need to
  get rare enough that we can throw them under the bus.
  There are still a few of them in use, but the chips are
  all more than 10 years old by now and eventually they
  will stop needing kernel updates.

- sparc32 kernels should start supporting more than 192MB of
  lowmem (or stop existing). Apparently there are Leon3
  machines with up to 2GB of RAM.

- mips32 has a hardware lowmem limit of 512MB, and I think
  we can live with that because they tend to have less actual
  RAM. There is one important chip (mt7621) that supports
  512MB RAM in machines with real users, and apparently that
  number goes down to 448MB without highmem.

- arc/csky/microblaze/xtensa all support highmem in theory,
  but I am not aware of anyone actually needing it any more.

- Lastly, there has to be some executive decision to actually
  do it as there will always be /some/ systems that are
  affected in the end. I don't think we can do enough of
  the mitigation work done for arm32 for this year's longterm
  kernel, but probably enough that we can agree on a
  deadline at the Tokyo LPC kernel summit, and maybe remove
  highmem after the 2026 longterm kernel.

I'll try to collect more data from affected users about what
will really break for them, and what I may have missed.

     Arnd

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH v3 06/10] x86: drop SWIOTLB for PAE
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (4 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 05/10] x86: remove HIGHMEM64G support Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Drop CONFIG_SWIOTLB " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 07/10] x86: drop support for CONFIG_HIGHPTE Arnd Bergmann
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

Since kernels with and without CONFIG_X86_PAE are now limited
to the low 4GB of physical address space, there is no need to
use swiotlb any more, so stop selecting this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d785cb368125..2810482dc183 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1461,7 +1461,6 @@ config X86_PAE
 	bool "PAE (Physical Address Extension) Support"
 	depends on X86_32 && X86_HAVE_PAE
 	select PHYS_ADDR_T_64BIT
-	select SWIOTLB
 	help
 	  PAE is required for NX support, and furthermore enables
 	  larger swapspace support for non-overcommit purposes. It
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/mm: Drop CONFIG_SWIOTLB for PAE
  2025-02-26 21:37 ` [PATCH v3 06/10] x86: drop SWIOTLB for PAE Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     a8331594036f22dcf037f1a75358bd0985c84cd9
Gitweb:        https://git.kernel.org/tip/a8331594036f22dcf037f1a75358bd0985c84cd9
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:10 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:21:59 +01:00

x86/mm: Drop CONFIG_SWIOTLB for PAE

Since kernels with and without CONFIG_X86_PAE are now limited
to the low 4GB of physical address space, there is no need to
use swiotlb any more, so stop selecting this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-7-arnd@kernel.org
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 737a0c6..0e0ec2c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1462,7 +1462,6 @@ config X86_PAE
 	bool "PAE (Physical Address Extension) Support"
 	depends on X86_32 && X86_HAVE_PAE
 	select PHYS_ADDR_T_64BIT
-	select SWIOTLB
 	help
 	  PAE is required for NX support, and furthermore enables
 	  larger swapspace support for non-overcommit purposes. It

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 07/10] x86: drop support for CONFIG_HIGHPTE
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (5 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 06/10] x86: drop SWIOTLB for PAE Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Drop " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only Arnd Bergmann
                   ` (3 subsequent siblings)
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

From: Arnd Bergmann <arnd@arndb.de>

With the maximum amount of RAM now 4GB, there is very little point
to still have PTE pages in highmem. Drop this for simplification.

The only other architecture supporting HIGHPTE is 32-bit arm, and
once that feature is removed as well, the highpte logic can be
dropped from common code as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../admin-guide/kernel-parameters.txt         |  7 -----
 arch/x86/Kconfig                              |  9 -------
 arch/x86/include/asm/pgalloc.h                |  5 ----
 arch/x86/mm/pgtable.c                         | 27 +------------------
 4 files changed, 1 insertion(+), 47 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 8f923770a566..93177630cefb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7668,13 +7668,6 @@
 				16 - SIGBUS faults
 			Example: user_debug=31
 
-	userpte=
-			[X86,EARLY] Flags controlling user PTE allocations.
-
-				nohigh = do not allocate PTE pages in
-					HIGHMEM regardless of setting
-					of CONFIG_HIGHPTE.
-
 	vdso=		[X86,SH,SPARC]
 			On X86_32, this is an alias for vdso32=.  Otherwise:
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2810482dc183..aba32f88870d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1627,15 +1627,6 @@ config X86_PMEM_LEGACY
 
 	  Say Y if unsure.
 
-config HIGHPTE
-	bool "Allocate 3rd-level pagetables from highmem"
-	depends on HIGHMEM
-	help
-	  The VM uses one page table entry for each page of physical memory.
-	  For systems with a lot of RAM, this can be wasteful of precious
-	  low memory.  Setting this option will put user-space page table
-	  entries in high memory.
-
 config X86_CHECK_BIOS_CORRUPTION
 	bool "Check for low memory corruption"
 	help
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index dd4841231bb9..a33147520044 100644
--- a/arch/x86/include/asm/pgalloc.h
+++ b/arch/x86/include/asm/pgalloc.h
@@ -29,11 +29,6 @@ static inline void paravirt_release_pud(unsigned long pfn) {}
 static inline void paravirt_release_p4d(unsigned long pfn) {}
 #endif
 
-/*
- * Flags to use when allocating a user page table page.
- */
-extern gfp_t __userpte_alloc_gfp;
-
 #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
 /*
  * Instead of one PGD, we acquire two PGDs.  Being order-1, it is
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 1fef5ad32d5a..94b5601f2cd8 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -12,12 +12,6 @@ phys_addr_t physical_mask __ro_after_init = (1ULL << __PHYSICAL_MASK_SHIFT) - 1;
 EXPORT_SYMBOL(physical_mask);
 #endif
 
-#ifdef CONFIG_HIGHPTE
-#define PGTABLE_HIGHMEM __GFP_HIGHMEM
-#else
-#define PGTABLE_HIGHMEM 0
-#endif
-
 #ifndef CONFIG_PARAVIRT
 #ifndef CONFIG_PT_RECLAIM
 static inline
@@ -37,29 +31,10 @@ void paravirt_tlb_remove_table(struct mmu_gather *tlb, void *table)
 #endif /* !CONFIG_PT_RECLAIM */
 #endif /* !CONFIG_PARAVIRT */
 
-gfp_t __userpte_alloc_gfp = GFP_PGTABLE_USER | PGTABLE_HIGHMEM;
-
 pgtable_t pte_alloc_one(struct mm_struct *mm)
 {
-	return __pte_alloc_one(mm, __userpte_alloc_gfp);
-}
-
-static int __init setup_userpte(char *arg)
-{
-	if (!arg)
-		return -EINVAL;
-
-	/*
-	 * "userpte=nohigh" disables allocation of user pagetables in
-	 * high memory.
-	 */
-	if (strcmp(arg, "nohigh") == 0)
-		__userpte_alloc_gfp &= ~__GFP_HIGHMEM;
-	else
-		return -EINVAL;
-	return 0;
+	return __pte_alloc_one(mm, GFP_PGTABLE_USER);
 }
-early_param("userpte", setup_userpte);
 
 void ___pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
 {
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/mm: Drop support for CONFIG_HIGHPTE
  2025-02-26 21:37 ` [PATCH v3 07/10] x86: drop support for CONFIG_HIGHPTE Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     0081fdeccbf610499b79784998b1fd36783209dd
Gitweb:        https://git.kernel.org/tip/0081fdeccbf610499b79784998b1fd36783209dd
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:11 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:22:06 +01:00

x86/mm: Drop support for CONFIG_HIGHPTE

With the maximum amount of RAM now 4GB, there is very little point
to still have PTE pages in highmem. Drop this for simplification.

The only other architecture supporting HIGHPTE is 32-bit arm, and
once that feature is removed as well, the highpte logic can be
dropped from common code as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-8-arnd@kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |  7 +----
 arch/x86/Kconfig                                |  9 +-----
 arch/x86/include/asm/pgalloc.h                  |  5 +---
 arch/x86/mm/pgtable.c                           | 27 +----------------
 4 files changed, 1 insertion(+), 47 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 8f92377..9317763 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7668,13 +7668,6 @@
 				16 - SIGBUS faults
 			Example: user_debug=31
 
-	userpte=
-			[X86,EARLY] Flags controlling user PTE allocations.
-
-				nohigh = do not allocate PTE pages in
-					HIGHMEM regardless of setting
-					of CONFIG_HIGHPTE.
-
 	vdso=		[X86,SH,SPARC]
 			On X86_32, this is an alias for vdso32=.  Otherwise:
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0e0ec2c..73eeaf2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1628,15 +1628,6 @@ config X86_PMEM_LEGACY
 
 	  Say Y if unsure.
 
-config HIGHPTE
-	bool "Allocate 3rd-level pagetables from highmem"
-	depends on HIGHMEM
-	help
-	  The VM uses one page table entry for each page of physical memory.
-	  For systems with a lot of RAM, this can be wasteful of precious
-	  low memory.  Setting this option will put user-space page table
-	  entries in high memory.
-
 config X86_CHECK_BIOS_CORRUPTION
 	bool "Check for low memory corruption"
 	help
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index dd48412..a331475 100644
--- a/arch/x86/include/asm/pgalloc.h
+++ b/arch/x86/include/asm/pgalloc.h
@@ -29,11 +29,6 @@ static inline void paravirt_release_pud(unsigned long pfn) {}
 static inline void paravirt_release_p4d(unsigned long pfn) {}
 #endif
 
-/*
- * Flags to use when allocating a user page table page.
- */
-extern gfp_t __userpte_alloc_gfp;
-
 #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
 /*
  * Instead of one PGD, we acquire two PGDs.  Being order-1, it is
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index b1c1f72..cec321f 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -12,35 +12,10 @@ phys_addr_t physical_mask __ro_after_init = (1ULL << __PHYSICAL_MASK_SHIFT) - 1;
 EXPORT_SYMBOL(physical_mask);
 #endif
 
-#ifdef CONFIG_HIGHPTE
-#define PGTABLE_HIGHMEM __GFP_HIGHMEM
-#else
-#define PGTABLE_HIGHMEM 0
-#endif
-
-gfp_t __userpte_alloc_gfp = GFP_PGTABLE_USER | PGTABLE_HIGHMEM;
-
 pgtable_t pte_alloc_one(struct mm_struct *mm)
 {
-	return __pte_alloc_one(mm, __userpte_alloc_gfp);
-}
-
-static int __init setup_userpte(char *arg)
-{
-	if (!arg)
-		return -EINVAL;
-
-	/*
-	 * "userpte=nohigh" disables allocation of user pagetables in
-	 * high memory.
-	 */
-	if (strcmp(arg, "nohigh") == 0)
-		__userpte_alloc_gfp &= ~__GFP_HIGHMEM;
-	else
-		return -EINVAL;
-	return 0;
+	return __pte_alloc_one(mm, GFP_PGTABLE_USER);
 }
-early_param("userpte", setup_userpte);
 
 void ___pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
 {

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (6 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 07/10] x86: drop support for CONFIG_HIGHPTE Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/cpu: Document CONFIG_X86_INTEL_MID " tip-bot2 for Arnd Bergmann
  2025-02-28 16:20   ` [PATCH v3 08/10] x86: document X86_INTEL_MID " Ferry Toth
  2025-02-26 21:37 ` [PATCH v3 09/10] x86: remove old STA2x11 support Arnd Bergmann
                   ` (2 subsequent siblings)
  10 siblings, 2 replies; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox, Ferry Toth

From: Arnd Bergmann <arnd@arndb.de>

The X86_INTEL_MID code was originally introduced for the 32-bit
Moorestown/Medfield/Clovertrail platform, later the 64-bit
Merrifield/Moorefield variants were added, but the final Morganfield
14nm platform was canceled before it hit the market.

To help users understand what the option actually refers to, update the
help text, and add a dependency on 64-bit kernels.

Ferry confirmed that all the hardware can run 64-bit kernels these days,
but is still testing 32-bit kernels on the Intel Edison board, so this
remains possible, but is guarded by a CONFIG_EXPERT dependency now,
to gently push remaining users towards using CONFIG_64BIT.

Cc: Ferry Toth <fntoth@gmail.com>
Link: https://lore.kernel.org/lkml/d890eecc-97de-4abf-8e0e-b881d5db5c1d@gmail.com/
Acked-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig | 50 ++++++++++++++++++++++++++++--------------------
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index aba32f88870d..42dd3c58abfb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -548,12 +548,12 @@ config X86_EXTENDED_PLATFORM
 		RDC R-321x SoC
 		SGI 320/540 (Visual Workstation)
 		STA2X11-based (e.g. Northville)
-		Moorestown MID devices
 
 	  64-bit platforms (CONFIG_64BIT=y):
 		Numascale NumaChip
 		ScaleMP vSMP
 		SGI Ultraviolet
+		Merrifield/Moorefield MID devices
 
 	  If you have one of these systems, or if you want to build a
 	  generic distribution kernel, say Y here - otherwise say N.
@@ -598,8 +598,31 @@ config X86_UV
 	  This option is needed in order to support SGI Ultraviolet systems.
 	  If you don't have one of these, you should say N here.
 
-# Following is an alphabetically sorted list of 32 bit extended platforms
-# Please maintain the alphabetic order if and when there are additions
+config X86_INTEL_MID
+	bool "Intel Z34xx/Z35xx MID platform support"
+	depends on X86_EXTENDED_PLATFORM
+	depends on X86_PLATFORM_DEVICES
+	depends on PCI
+	depends on X86_64 || (EXPERT && PCI_GOANY)
+	depends on X86_IO_APIC
+	select I2C
+	select DW_APB_TIMER
+	select INTEL_SCU_PCI
+	help
+	  Select to build a kernel capable of supporting 64-bit Intel MID
+	  (Mobile Internet Device) platform systems which do not have
+	  the PCI legacy interfaces.
+
+	  The only supported devices are the 22nm Merrified (Z34xx)
+	  and Moorefield (Z35xx) SoC used in the Intel Edison board and
+	  a small number of Android devices such as the Asus Zenfone 2,
+	  Asus FonePad 8 and Dell Venue 7.
+
+	  If you are building for a PC class system or non-MID tablet
+	  SoCs like Bay Trail (Z36xx/Z37xx), say N here.
+
+	  Intel MID platforms are based on an Intel processor and chipset which
+	  consume less power than most of the x86 derivatives.
 
 config X86_GOLDFISH
 	bool "Goldfish (Virtual Platform)"
@@ -609,6 +632,9 @@ config X86_GOLDFISH
 	  for Android development. Unless you are building for the Android
 	  Goldfish emulator say N here.
 
+# Following is an alphabetically sorted list of 32 bit extended platforms
+# Please maintain the alphabetic order if and when there are additions
+
 config X86_INTEL_CE
 	bool "CE4100 TV platform"
 	depends on PCI
@@ -624,24 +650,6 @@ config X86_INTEL_CE
 	  This option compiles in support for the CE4100 SOC for settop
 	  boxes and media devices.
 
-config X86_INTEL_MID
-	bool "Intel MID platform support"
-	depends on X86_EXTENDED_PLATFORM
-	depends on X86_PLATFORM_DEVICES
-	depends on PCI
-	depends on X86_64 || (PCI_GOANY && X86_32)
-	depends on X86_IO_APIC
-	select I2C
-	select DW_APB_TIMER
-	select INTEL_SCU_PCI
-	help
-	  Select to build a kernel capable of supporting Intel MID (Mobile
-	  Internet Device) platform systems which do not have the PCI legacy
-	  interfaces. If you are building for a PC class system say N here.
-
-	  Intel MID platforms are based on an Intel processor and chipset which
-	  consume less power than most of the x86 derivatives.
-
 config X86_INTEL_QUARK
 	bool "Intel Quark platform support"
 	depends on X86_32
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/cpu: Document CONFIG_X86_INTEL_MID as 64-bit-only
  2025-02-26 21:37 ` [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  2025-02-28 16:20   ` [PATCH v3 08/10] x86: document X86_INTEL_MID " Ferry Toth
  1 sibling, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Andy Shevchenko, Linus Torvalds, x86,
	linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     ca5955dd5f08727605723b60767fbf2cc3d54046
Gitweb:        https://git.kernel.org/tip/ca5955dd5f08727605723b60767fbf2cc3d54046
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:12 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:22:07 +01:00

x86/cpu: Document CONFIG_X86_INTEL_MID as 64-bit-only

The X86_INTEL_MID code was originally introduced for the 32-bit
Moorestown/Medfield/Clovertrail platform, later the 64-bit
Merrifield/Moorefield variants were added, but the final Morganfield
14nm platform was canceled before it hit the market.

To help users understand what the option actually refers to, update the
help text, and add a dependency on 64-bit kernels.

Ferry confirmed that all the hardware can run 64-bit kernels these days,
but is still testing 32-bit kernels on the Intel Edison board, so this
remains possible, but is guarded by a CONFIG_EXPERT dependency now,
to gently push remaining users towards using CONFIG_64BIT.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Andy Shevchenko <andy@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-9-arnd@kernel.org
---
 arch/x86/Kconfig | 50 +++++++++++++++++++++++++++--------------------
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 73eeaf2..acd4d73 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -549,12 +549,12 @@ config X86_EXTENDED_PLATFORM
 		RDC R-321x SoC
 		SGI 320/540 (Visual Workstation)
 		STA2X11-based (e.g. Northville)
-		Moorestown MID devices
 
 	  64-bit platforms (CONFIG_64BIT=y):
 		Numascale NumaChip
 		ScaleMP vSMP
 		SGI Ultraviolet
+		Merrifield/Moorefield MID devices
 
 	  If you have one of these systems, or if you want to build a
 	  generic distribution kernel, say Y here - otherwise say N.
@@ -599,8 +599,31 @@ config X86_UV
 	  This option is needed in order to support SGI Ultraviolet systems.
 	  If you don't have one of these, you should say N here.
 
-# Following is an alphabetically sorted list of 32 bit extended platforms
-# Please maintain the alphabetic order if and when there are additions
+config X86_INTEL_MID
+	bool "Intel Z34xx/Z35xx MID platform support"
+	depends on X86_EXTENDED_PLATFORM
+	depends on X86_PLATFORM_DEVICES
+	depends on PCI
+	depends on X86_64 || (EXPERT && PCI_GOANY)
+	depends on X86_IO_APIC
+	select I2C
+	select DW_APB_TIMER
+	select INTEL_SCU_PCI
+	help
+	  Select to build a kernel capable of supporting 64-bit Intel MID
+	  (Mobile Internet Device) platform systems which do not have
+	  the PCI legacy interfaces.
+
+	  The only supported devices are the 22nm Merrified (Z34xx)
+	  and Moorefield (Z35xx) SoC used in the Intel Edison board and
+	  a small number of Android devices such as the Asus Zenfone 2,
+	  Asus FonePad 8 and Dell Venue 7.
+
+	  If you are building for a PC class system or non-MID tablet
+	  SoCs like Bay Trail (Z36xx/Z37xx), say N here.
+
+	  Intel MID platforms are based on an Intel processor and chipset which
+	  consume less power than most of the x86 derivatives.
 
 config X86_GOLDFISH
 	bool "Goldfish (Virtual Platform)"
@@ -610,6 +633,9 @@ config X86_GOLDFISH
 	  for Android development. Unless you are building for the Android
 	  Goldfish emulator say N here.
 
+# Following is an alphabetically sorted list of 32 bit extended platforms
+# Please maintain the alphabetic order if and when there are additions
+
 config X86_INTEL_CE
 	bool "CE4100 TV platform"
 	depends on PCI
@@ -625,24 +651,6 @@ config X86_INTEL_CE
 	  This option compiles in support for the CE4100 SOC for settop
 	  boxes and media devices.
 
-config X86_INTEL_MID
-	bool "Intel MID platform support"
-	depends on X86_EXTENDED_PLATFORM
-	depends on X86_PLATFORM_DEVICES
-	depends on PCI
-	depends on X86_64 || (PCI_GOANY && X86_32)
-	depends on X86_IO_APIC
-	select I2C
-	select DW_APB_TIMER
-	select INTEL_SCU_PCI
-	help
-	  Select to build a kernel capable of supporting Intel MID (Mobile
-	  Internet Device) platform systems which do not have the PCI legacy
-	  interfaces. If you are building for a PC class system say N here.
-
-	  Intel MID platforms are based on an Intel processor and chipset which
-	  consume less power than most of the x86 derivatives.
-
 config X86_INTEL_QUARK
 	bool "Intel Quark platform support"
 	depends on X86_32

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only
  2025-02-26 21:37 ` [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/cpu: Document CONFIG_X86_INTEL_MID " tip-bot2 for Arnd Bergmann
@ 2025-02-28 16:20   ` Ferry Toth
  2025-02-28 18:40     ` Andy Shevchenko
  1 sibling, 1 reply; 29+ messages in thread
From: Ferry Toth @ 2025-02-28 16:20 UTC (permalink / raw)
  To: Arnd Bergmann, linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox

Hi,

On 26-02-2025 22:37, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The X86_INTEL_MID code was originally introduced for the 32-bit
> Moorestown/Medfield/Clovertrail platform, later the 64-bit
> Merrifield/Moorefield variants were added, but the final Morganfield
> 14nm platform was canceled before it hit the market.
>
> To help users understand what the option actually refers to, update the
> help text, and add a dependency on 64-bit kernels.
>
> Ferry confirmed that all the hardware can run 64-bit kernels these days,
> but is still testing 32-bit kernels on the Intel Edison board, so this
> remains possible, but is guarded by a CONFIG_EXPERT dependency now,
> to gently push remaining users towards using CONFIG_64BIT.

That is a bit more than I said :-) I only know of Merrifield, as Andy 
removed the SFI bits and got ACPI working. For the other platforms I 
don't know the status. Additionally there are pieces of code where 32b 
runs substantially faster than 64b (I know of at least crc32c).

Maybe Andy can confirm the other platforms?

> Cc: Ferry Toth <fntoth@gmail.com>
> Link: https://lore.kernel.org/lkml/d890eecc-97de-4abf-8e0e-b881d5db5c1d@gmail.com/
> Acked-by: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   arch/x86/Kconfig | 50 ++++++++++++++++++++++++++++--------------------
>   1 file changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index aba32f88870d..42dd3c58abfb 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -548,12 +548,12 @@ config X86_EXTENDED_PLATFORM
>   		RDC R-321x SoC
>   		SGI 320/540 (Visual Workstation)
>   		STA2X11-based (e.g. Northville)
> -		Moorestown MID devices
>   
>   	  64-bit platforms (CONFIG_64BIT=y):
>   		Numascale NumaChip
>   		ScaleMP vSMP
>   		SGI Ultraviolet
> +		Merrifield/Moorefield MID devices
>   
>   	  If you have one of these systems, or if you want to build a
>   	  generic distribution kernel, say Y here - otherwise say N.
> @@ -598,8 +598,31 @@ config X86_UV
>   	  This option is needed in order to support SGI Ultraviolet systems.
>   	  If you don't have one of these, you should say N here.
>   
> -# Following is an alphabetically sorted list of 32 bit extended platforms
> -# Please maintain the alphabetic order if and when there are additions
> +config X86_INTEL_MID
> +	bool "Intel Z34xx/Z35xx MID platform support"
> +	depends on X86_EXTENDED_PLATFORM
> +	depends on X86_PLATFORM_DEVICES
> +	depends on PCI
> +	depends on X86_64 || (EXPERT && PCI_GOANY)
> +	depends on X86_IO_APIC
> +	select I2C
> +	select DW_APB_TIMER
> +	select INTEL_SCU_PCI
> +	help
> +	  Select to build a kernel capable of supporting 64-bit Intel MID
> +	  (Mobile Internet Device) platform systems which do not have
> +	  the PCI legacy interfaces.
> +
> +	  The only supported devices are the 22nm Merrified (Z34xx)
> +	  and Moorefield (Z35xx) SoC used in the Intel Edison board and
> +	  a small number of Android devices such as the Asus Zenfone 2,
> +	  Asus FonePad 8 and Dell Venue 7.
> +
> +	  If you are building for a PC class system or non-MID tablet
> +	  SoCs like Bay Trail (Z36xx/Z37xx), say N here.
> +
> +	  Intel MID platforms are based on an Intel processor and chipset which
> +	  consume less power than most of the x86 derivatives.
>   
>   config X86_GOLDFISH
>   	bool "Goldfish (Virtual Platform)"
> @@ -609,6 +632,9 @@ config X86_GOLDFISH
>   	  for Android development. Unless you are building for the Android
>   	  Goldfish emulator say N here.
>   
> +# Following is an alphabetically sorted list of 32 bit extended platforms
> +# Please maintain the alphabetic order if and when there are additions
> +
>   config X86_INTEL_CE
>   	bool "CE4100 TV platform"
>   	depends on PCI
> @@ -624,24 +650,6 @@ config X86_INTEL_CE
>   	  This option compiles in support for the CE4100 SOC for settop
>   	  boxes and media devices.
>   
> -config X86_INTEL_MID
> -	bool "Intel MID platform support"
> -	depends on X86_EXTENDED_PLATFORM
> -	depends on X86_PLATFORM_DEVICES
> -	depends on PCI
> -	depends on X86_64 || (PCI_GOANY && X86_32)
> -	depends on X86_IO_APIC
> -	select I2C
> -	select DW_APB_TIMER
> -	select INTEL_SCU_PCI
> -	help
> -	  Select to build a kernel capable of supporting Intel MID (Mobile
> -	  Internet Device) platform systems which do not have the PCI legacy
> -	  interfaces. If you are building for a PC class system say N here.
> -
> -	  Intel MID platforms are based on an Intel processor and chipset which
> -	  consume less power than most of the x86 derivatives.
> -
>   config X86_INTEL_QUARK
>   	bool "Intel Quark platform support"
>   	depends on X86_32

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only
  2025-02-28 16:20   ` [PATCH v3 08/10] x86: document X86_INTEL_MID " Ferry Toth
@ 2025-02-28 18:40     ` Andy Shevchenko
  0 siblings, 0 replies; 29+ messages in thread
From: Andy Shevchenko @ 2025-02-28 18:40 UTC (permalink / raw)
  To: Ferry Toth
  Cc: Arnd Bergmann, linux-kernel, x86, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Linus Torvalds, Matthew Wilcox

On Fri, Feb 28, 2025 at 05:20:54PM +0100, Ferry Toth wrote:
> Hi,
> 
> On 26-02-2025 22:37, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> > 
> > The X86_INTEL_MID code was originally introduced for the 32-bit
> > Moorestown/Medfield/Clovertrail platform, later the 64-bit
> > Merrifield/Moorefield variants were added, but the final Morganfield
> > 14nm platform was canceled before it hit the market.
> > 
> > To help users understand what the option actually refers to, update the
> > help text, and add a dependency on 64-bit kernels.
> > 
> > Ferry confirmed that all the hardware can run 64-bit kernels these days,
> > but is still testing 32-bit kernels on the Intel Edison board, so this
> > remains possible, but is guarded by a CONFIG_EXPERT dependency now,
> > to gently push remaining users towards using CONFIG_64BIT.
> 
> That is a bit more than I said :-) I only know of Merrifield, as Andy
> removed the SFI bits and got ACPI working. For the other platforms I don't
> know the status. Additionally there are pieces of code where 32b runs
> substantially faster than 64b (I know of at least crc32c).
> 
> Maybe Andy can confirm the other platforms?

Listed SoCs are all capable of running 64-bit code.

Telling that they 64-bit only is a bit of a lie but it seems for good. :-)

OTOH I dunno if there is still a plan by community to resurrect Intel Medifield
and Clovertrail (there are phones in a working shape still around), but either
way they will need to switch to ACPI and U-boot to begin with and that's in my
knowledge not trivial and not easy task. That said, I don't think it will ever
happen.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH v3 09/10] x86: remove old STA2x11 support
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (7 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/pci: Remove " tip-bot2 for Arnd Bergmann
  2025-02-26 21:37 ` [PATCH v3 10/10] x86: only allow EISA for 32-bit Arnd Bergmann
  2025-02-27 10:34 ` [PATCH v3 00/10] x86: 32-bit cleanups Ingo Molnar
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox, Davide Ciminaghi

From: Arnd Bergmann <arnd@arndb.de>

ST ConneXt STA2x11 was an interface chip for Atom E6xx processors,
using a number of components usually found on Arm SoCs. Most of this
was merged upstream, but it was never complete enough to actually work
and has been abandoned for many years.

We already had an agreement on removing it in 2022, but nobody ever
submitted the patch to do it.

Without STA2x11, the CONFIG_X86_32_NON_STANDARD no longer has any
use.

Suggested-by:  Davide Ciminaghi <ciminaghi@gnudd.com>
Link: https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig               |  32 +----
 arch/x86/include/asm/sta2x11.h |  13 --
 arch/x86/pci/Makefile          |   2 -
 arch/x86/pci/sta2x11-fixup.c   | 233 ---------------------------------
 4 files changed, 3 insertions(+), 277 deletions(-)
 delete mode 100644 arch/x86/include/asm/sta2x11.h
 delete mode 100644 arch/x86/pci/sta2x11-fixup.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 42dd3c58abfb..14dd7b5abd5d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -547,7 +547,6 @@ config X86_EXTENDED_PLATFORM
 		AMD Elan
 		RDC R-321x SoC
 		SGI 320/540 (Visual Workstation)
-		STA2X11-based (e.g. Northville)
 
 	  64-bit platforms (CONFIG_64BIT=y):
 		Numascale NumaChip
@@ -731,18 +730,6 @@ config X86_RDC321X
 	  as R-8610-(G).
 	  If you don't have one of these chips, you should say N here.
 
-config X86_32_NON_STANDARD
-	bool "Support non-standard 32-bit SMP architectures"
-	depends on X86_32 && SMP
-	depends on X86_EXTENDED_PLATFORM
-	help
-	  This option compiles in the STA2X11 default
-	  subarchitecture.  It is intended for a generic binary
-	  kernel. If you select them all, kernel will probe it one by
-	  one and will fallback to default.
-
-# Alphabetically sorted list of Non standard 32 bit platforms
-
 config X86_SUPPORTS_MEMORY_FAILURE
 	def_bool y
 	# MCE code calls memory_failure():
@@ -752,19 +739,6 @@ config X86_SUPPORTS_MEMORY_FAILURE
 	depends on X86_64 || !SPARSEMEM
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 
-config STA2X11
-	bool "STA2X11 Companion Chip Support"
-	depends on X86_32_NON_STANDARD && PCI
-	select SWIOTLB
-	select MFD_STA2X11
-	select GPIOLIB
-	help
-	  This adds support for boards based on the STA2X11 IO-Hub,
-	  a.k.a. "ConneXt". The chip is used in place of the standard
-	  PC chipset, so all "standard" peripherals are missing. If this
-	  option is selected the kernel will still be able to boot on
-	  standard PC machines.
-
 config X86_32_IRIS
 	tristate "Eurobraille/Iris poweroff module"
 	depends on X86_32
@@ -1102,7 +1076,7 @@ config UP_LATE_INIT
 config X86_UP_APIC
 	bool "Local APIC support on uniprocessors" if !PCI_MSI
 	default PCI_MSI
-	depends on X86_32 && !SMP && !X86_32_NON_STANDARD
+	depends on X86_32 && !SMP
 	help
 	  A local APIC (Advanced Programmable Interrupt Controller) is an
 	  integrated interrupt controller in the CPU. If you have a single-CPU
@@ -1127,7 +1101,7 @@ config X86_UP_IOAPIC
 
 config X86_LOCAL_APIC
 	def_bool y
-	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
+	depends on X86_64 || SMP || X86_UP_APIC || PCI_MSI
 	select IRQ_DOMAIN_HIERARCHY
 
 config ACPI_MADT_WAKEUP
@@ -1589,7 +1563,7 @@ config ARCH_FLATMEM_ENABLE
 
 config ARCH_SPARSEMEM_ENABLE
 	def_bool y
-	depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
+	depends on X86_64 || NUMA || X86_32
 	select SPARSEMEM_STATIC if X86_32
 	select SPARSEMEM_VMEMMAP_ENABLE if X86_64
 
diff --git a/arch/x86/include/asm/sta2x11.h b/arch/x86/include/asm/sta2x11.h
deleted file mode 100644
index e0975e9c4f47..000000000000
--- a/arch/x86/include/asm/sta2x11.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Header file for STMicroelectronics ConneXt (STA2X11) IOHub
- */
-#ifndef __ASM_STA2X11_H
-#define __ASM_STA2X11_H
-
-#include <linux/pci.h>
-
-/* This needs to be called from the MFD to configure its sub-devices */
-struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev);
-
-#endif /* __ASM_STA2X11_H */
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index 48bcada5cabe..4933fb337983 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -12,8 +12,6 @@ obj-$(CONFIG_X86_INTEL_CE)      += ce4100.o
 obj-$(CONFIG_ACPI)		+= acpi.o
 obj-y				+= legacy.o irq.o
 
-obj-$(CONFIG_STA2X11)           += sta2x11-fixup.o
-
 obj-$(CONFIG_X86_NUMACHIP)	+= numachip.o
 
 obj-$(CONFIG_X86_INTEL_MID)	+= intel_mid_pci.o
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
deleted file mode 100644
index 8c8ddc4dcc08..000000000000
--- a/arch/x86/pci/sta2x11-fixup.c
+++ /dev/null
@@ -1,233 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * DMA translation between STA2x11 AMBA memory mapping and the x86 memory mapping
- *
- * ST Microelectronics ConneXt (STA2X11/STA2X10)
- *
- * Copyright (c) 2010-2011 Wind River Systems, Inc.
- */
-
-#include <linux/pci.h>
-#include <linux/pci_ids.h>
-#include <linux/export.h>
-#include <linux/list.h>
-#include <linux/dma-map-ops.h>
-#include <linux/swiotlb.h>
-#include <asm/iommu.h>
-#include <asm/sta2x11.h>
-
-#define STA2X11_SWIOTLB_SIZE (4*1024*1024)
-
-/*
- * We build a list of bus numbers that are under the ConneXt. The
- * main bridge hosts 4 busses, which are the 4 endpoints, in order.
- */
-#define STA2X11_NR_EP		4	/* 0..3 included */
-#define STA2X11_NR_FUNCS	8	/* 0..7 included */
-#define STA2X11_AMBA_SIZE	(512 << 20)
-
-struct sta2x11_ahb_regs { /* saved during suspend */
-	u32 base, pexlbase, pexhbase, crw;
-};
-
-struct sta2x11_mapping {
-	int is_suspended;
-	struct sta2x11_ahb_regs regs[STA2X11_NR_FUNCS];
-};
-
-struct sta2x11_instance {
-	struct list_head list;
-	int bus0;
-	struct sta2x11_mapping map[STA2X11_NR_EP];
-};
-
-static LIST_HEAD(sta2x11_instance_list);
-
-/* At probe time, record new instances of this bridge (likely one only) */
-static void sta2x11_new_instance(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-
-	instance = kzalloc(sizeof(*instance), GFP_ATOMIC);
-	if (!instance)
-		return;
-	/* This has a subordinate bridge, with 4 more-subordinate ones */
-	instance->bus0 = pdev->subordinate->number + 1;
-
-	if (list_empty(&sta2x11_instance_list)) {
-		int size = STA2X11_SWIOTLB_SIZE;
-		/* First instance: register your own swiotlb area */
-		dev_info(&pdev->dev, "Using SWIOTLB (size %i)\n", size);
-		if (swiotlb_init_late(size, GFP_DMA, NULL))
-			dev_emerg(&pdev->dev, "init swiotlb failed\n");
-	}
-	list_add(&instance->list, &sta2x11_instance_list);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, 0xcc17, sta2x11_new_instance);
-
-/*
- * Utility functions used in this file from below
- */
-static struct sta2x11_instance *sta2x11_pdev_to_instance(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-	int ep;
-
-	list_for_each_entry(instance, &sta2x11_instance_list, list) {
-		ep = pdev->bus->number - instance->bus0;
-		if (ep >= 0 && ep < STA2X11_NR_EP)
-			return instance;
-	}
-	return NULL;
-}
-
-static int sta2x11_pdev_to_ep(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-
-	instance = sta2x11_pdev_to_instance(pdev);
-	if (!instance)
-		return -1;
-
-	return pdev->bus->number - instance->bus0;
-}
-
-/* This is exported, as some devices need to access the MFD registers */
-struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev)
-{
-	return sta2x11_pdev_to_instance(pdev);
-}
-EXPORT_SYMBOL(sta2x11_get_instance);
-
-/* At setup time, we use our own ops if the device is a ConneXt one */
-static void sta2x11_setup_pdev(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev);
-
-	if (!instance) /* either a sta2x11 bridge or another ST device */
-		return;
-
-	/* We must enable all devices as master, for audio DMA to work */
-	pci_set_master(pdev);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_setup_pdev);
-
-/*
- * At boot we must set up the mappings for the pcie-to-amba bridge.
- * It involves device access, and the same happens at suspend/resume time
- */
-
-#define AHB_MAPB		0xCA4
-#define AHB_CRW(i)		(AHB_MAPB + 0  + (i) * 0x10)
-#define AHB_CRW_SZMASK			0xfffffc00UL
-#define AHB_CRW_ENABLE			(1 << 0)
-#define AHB_CRW_WTYPE_MEM		(2 << 1)
-#define AHB_CRW_ROE			(1UL << 3)	/* Relax Order Ena */
-#define AHB_CRW_NSE			(1UL << 4)	/* No Snoop Enable */
-#define AHB_BASE(i)		(AHB_MAPB + 4  + (i) * 0x10)
-#define AHB_PEXLBASE(i)		(AHB_MAPB + 8  + (i) * 0x10)
-#define AHB_PEXHBASE(i)		(AHB_MAPB + 12 + (i) * 0x10)
-
-/* At probe time, enable mapping for each endpoint, using the pdev */
-static void sta2x11_map_ep(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev);
-	struct device *dev = &pdev->dev;
-	u32 amba_base, max_amba_addr;
-	int i, ret;
-
-	if (!instance)
-		return;
-
-	pci_read_config_dword(pdev, AHB_BASE(0), &amba_base);
-	max_amba_addr = amba_base + STA2X11_AMBA_SIZE - 1;
-
-	ret = dma_direct_set_offset(dev, 0, amba_base, STA2X11_AMBA_SIZE);
-	if (ret)
-		dev_err(dev, "sta2x11: could not set DMA offset\n");
-
-	dev->bus_dma_limit = max_amba_addr;
-	dma_set_mask_and_coherent(&pdev->dev, max_amba_addr);
-
-	/* Configure AHB mapping */
-	pci_write_config_dword(pdev, AHB_PEXLBASE(0), 0);
-	pci_write_config_dword(pdev, AHB_PEXHBASE(0), 0);
-	pci_write_config_dword(pdev, AHB_CRW(0), STA2X11_AMBA_SIZE |
-			       AHB_CRW_WTYPE_MEM | AHB_CRW_ENABLE);
-
-	/* Disable all the other windows */
-	for (i = 1; i < STA2X11_NR_FUNCS; i++)
-		pci_write_config_dword(pdev, AHB_CRW(i), 0);
-
-	dev_info(&pdev->dev,
-		 "sta2x11: Map EP %i: AMBA address %#8x-%#8x\n",
-		 sta2x11_pdev_to_ep(pdev), amba_base, max_amba_addr);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_map_ep);
-
-#ifdef CONFIG_PM /* Some register values must be saved and restored */
-
-static struct sta2x11_mapping *sta2x11_pdev_to_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-	int ep;
-
-	instance = sta2x11_pdev_to_instance(pdev);
-	if (!instance)
-		return NULL;
-	ep = sta2x11_pdev_to_ep(pdev);
-	return instance->map + ep;
-}
-
-static void suspend_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
-	int i;
-
-	if (!map)
-		return;
-
-	if (map->is_suspended)
-		return;
-	map->is_suspended = 1;
-
-	/* Save all window configs */
-	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
-		struct sta2x11_ahb_regs *regs = map->regs + i;
-
-		pci_read_config_dword(pdev, AHB_BASE(i), &regs->base);
-		pci_read_config_dword(pdev, AHB_PEXLBASE(i), &regs->pexlbase);
-		pci_read_config_dword(pdev, AHB_PEXHBASE(i), &regs->pexhbase);
-		pci_read_config_dword(pdev, AHB_CRW(i), &regs->crw);
-	}
-}
-DECLARE_PCI_FIXUP_SUSPEND(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, suspend_mapping);
-
-static void resume_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
-	int i;
-
-	if (!map)
-		return;
-
-
-	if (!map->is_suspended)
-		goto out;
-	map->is_suspended = 0;
-
-	/* Restore all window configs */
-	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
-		struct sta2x11_ahb_regs *regs = map->regs + i;
-
-		pci_write_config_dword(pdev, AHB_BASE(i), regs->base);
-		pci_write_config_dword(pdev, AHB_PEXLBASE(i), regs->pexlbase);
-		pci_write_config_dword(pdev, AHB_PEXHBASE(i), regs->pexhbase);
-		pci_write_config_dword(pdev, AHB_CRW(i), regs->crw);
-	}
-out:
-	pci_set_master(pdev); /* Like at boot, enable master on all devices */
-}
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, resume_mapping);
-
-#endif /* CONFIG_PM */
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/pci: Remove old STA2x11 support
  2025-02-26 21:37 ` [PATCH v3 09/10] x86: remove old STA2x11 support Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Davide Ciminaghi, Arnd Bergmann, Ingo Molnar, Bjorn Helgaas,
	Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     dcbb01fbb7aeed0fae4dc1389a36842c77f4f381
Gitweb:        https://git.kernel.org/tip/dcbb01fbb7aeed0fae4dc1389a36842c77f4f381
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:13 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:22:14 +01:00

x86/pci: Remove old STA2x11 support

ST ConneXt STA2x11 was an interface chip for Atom E6xx processors,
using a number of components usually found on Arm SoCs. Most of this
was merged upstream, but it was never complete enough to actually work
and has been abandoned for many years.

We already had an agreement on removing it in 2022, but nobody ever
submitted the patch to do it.

Without STA2x11, CONFIG_X86_32_NON_STANDARD no longer has any
use - remove it.

Suggested-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-10-arnd@kernel.org
---
 arch/x86/Kconfig               |  32 +----
 arch/x86/include/asm/sta2x11.h |  13 +--
 arch/x86/pci/Makefile          |   2 +-
 arch/x86/pci/sta2x11-fixup.c   | 233 +--------------------------------
 4 files changed, 3 insertions(+), 277 deletions(-)
 delete mode 100644 arch/x86/include/asm/sta2x11.h
 delete mode 100644 arch/x86/pci/sta2x11-fixup.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index acd4d73..383b145 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -548,7 +548,6 @@ config X86_EXTENDED_PLATFORM
 		AMD Elan
 		RDC R-321x SoC
 		SGI 320/540 (Visual Workstation)
-		STA2X11-based (e.g. Northville)
 
 	  64-bit platforms (CONFIG_64BIT=y):
 		Numascale NumaChip
@@ -732,18 +731,6 @@ config X86_RDC321X
 	  as R-8610-(G).
 	  If you don't have one of these chips, you should say N here.
 
-config X86_32_NON_STANDARD
-	bool "Support non-standard 32-bit SMP architectures"
-	depends on X86_32 && SMP
-	depends on X86_EXTENDED_PLATFORM
-	help
-	  This option compiles in the STA2X11 default
-	  subarchitecture.  It is intended for a generic binary
-	  kernel. If you select them all, kernel will probe it one by
-	  one and will fallback to default.
-
-# Alphabetically sorted list of Non standard 32 bit platforms
-
 config X86_SUPPORTS_MEMORY_FAILURE
 	def_bool y
 	# MCE code calls memory_failure():
@@ -753,19 +740,6 @@ config X86_SUPPORTS_MEMORY_FAILURE
 	depends on X86_64 || !SPARSEMEM
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 
-config STA2X11
-	bool "STA2X11 Companion Chip Support"
-	depends on X86_32_NON_STANDARD && PCI
-	select SWIOTLB
-	select MFD_STA2X11
-	select GPIOLIB
-	help
-	  This adds support for boards based on the STA2X11 IO-Hub,
-	  a.k.a. "ConneXt". The chip is used in place of the standard
-	  PC chipset, so all "standard" peripherals are missing. If this
-	  option is selected the kernel will still be able to boot on
-	  standard PC machines.
-
 config X86_32_IRIS
 	tristate "Eurobraille/Iris poweroff module"
 	depends on X86_32
@@ -1103,7 +1077,7 @@ config UP_LATE_INIT
 config X86_UP_APIC
 	bool "Local APIC support on uniprocessors" if !PCI_MSI
 	default PCI_MSI
-	depends on X86_32 && !SMP && !X86_32_NON_STANDARD
+	depends on X86_32 && !SMP
 	help
 	  A local APIC (Advanced Programmable Interrupt Controller) is an
 	  integrated interrupt controller in the CPU. If you have a single-CPU
@@ -1128,7 +1102,7 @@ config X86_UP_IOAPIC
 
 config X86_LOCAL_APIC
 	def_bool y
-	depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI
+	depends on X86_64 || SMP || X86_UP_APIC || PCI_MSI
 	select IRQ_DOMAIN_HIERARCHY
 
 config ACPI_MADT_WAKEUP
@@ -1590,7 +1564,7 @@ config ARCH_FLATMEM_ENABLE
 
 config ARCH_SPARSEMEM_ENABLE
 	def_bool y
-	depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
+	depends on X86_64 || NUMA || X86_32
 	select SPARSEMEM_STATIC if X86_32
 	select SPARSEMEM_VMEMMAP_ENABLE if X86_64
 
diff --git a/arch/x86/include/asm/sta2x11.h b/arch/x86/include/asm/sta2x11.h
deleted file mode 100644
index e0975e9..0000000
--- a/arch/x86/include/asm/sta2x11.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Header file for STMicroelectronics ConneXt (STA2X11) IOHub
- */
-#ifndef __ASM_STA2X11_H
-#define __ASM_STA2X11_H
-
-#include <linux/pci.h>
-
-/* This needs to be called from the MFD to configure its sub-devices */
-struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev);
-
-#endif /* __ASM_STA2X11_H */
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index 48bcada..4933fb3 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -12,8 +12,6 @@ obj-$(CONFIG_X86_INTEL_CE)      += ce4100.o
 obj-$(CONFIG_ACPI)		+= acpi.o
 obj-y				+= legacy.o irq.o
 
-obj-$(CONFIG_STA2X11)           += sta2x11-fixup.o
-
 obj-$(CONFIG_X86_NUMACHIP)	+= numachip.o
 
 obj-$(CONFIG_X86_INTEL_MID)	+= intel_mid_pci.o
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
deleted file mode 100644
index 8c8ddc4..0000000
--- a/arch/x86/pci/sta2x11-fixup.c
+++ /dev/null
@@ -1,233 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * DMA translation between STA2x11 AMBA memory mapping and the x86 memory mapping
- *
- * ST Microelectronics ConneXt (STA2X11/STA2X10)
- *
- * Copyright (c) 2010-2011 Wind River Systems, Inc.
- */
-
-#include <linux/pci.h>
-#include <linux/pci_ids.h>
-#include <linux/export.h>
-#include <linux/list.h>
-#include <linux/dma-map-ops.h>
-#include <linux/swiotlb.h>
-#include <asm/iommu.h>
-#include <asm/sta2x11.h>
-
-#define STA2X11_SWIOTLB_SIZE (4*1024*1024)
-
-/*
- * We build a list of bus numbers that are under the ConneXt. The
- * main bridge hosts 4 busses, which are the 4 endpoints, in order.
- */
-#define STA2X11_NR_EP		4	/* 0..3 included */
-#define STA2X11_NR_FUNCS	8	/* 0..7 included */
-#define STA2X11_AMBA_SIZE	(512 << 20)
-
-struct sta2x11_ahb_regs { /* saved during suspend */
-	u32 base, pexlbase, pexhbase, crw;
-};
-
-struct sta2x11_mapping {
-	int is_suspended;
-	struct sta2x11_ahb_regs regs[STA2X11_NR_FUNCS];
-};
-
-struct sta2x11_instance {
-	struct list_head list;
-	int bus0;
-	struct sta2x11_mapping map[STA2X11_NR_EP];
-};
-
-static LIST_HEAD(sta2x11_instance_list);
-
-/* At probe time, record new instances of this bridge (likely one only) */
-static void sta2x11_new_instance(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-
-	instance = kzalloc(sizeof(*instance), GFP_ATOMIC);
-	if (!instance)
-		return;
-	/* This has a subordinate bridge, with 4 more-subordinate ones */
-	instance->bus0 = pdev->subordinate->number + 1;
-
-	if (list_empty(&sta2x11_instance_list)) {
-		int size = STA2X11_SWIOTLB_SIZE;
-		/* First instance: register your own swiotlb area */
-		dev_info(&pdev->dev, "Using SWIOTLB (size %i)\n", size);
-		if (swiotlb_init_late(size, GFP_DMA, NULL))
-			dev_emerg(&pdev->dev, "init swiotlb failed\n");
-	}
-	list_add(&instance->list, &sta2x11_instance_list);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, 0xcc17, sta2x11_new_instance);
-
-/*
- * Utility functions used in this file from below
- */
-static struct sta2x11_instance *sta2x11_pdev_to_instance(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-	int ep;
-
-	list_for_each_entry(instance, &sta2x11_instance_list, list) {
-		ep = pdev->bus->number - instance->bus0;
-		if (ep >= 0 && ep < STA2X11_NR_EP)
-			return instance;
-	}
-	return NULL;
-}
-
-static int sta2x11_pdev_to_ep(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-
-	instance = sta2x11_pdev_to_instance(pdev);
-	if (!instance)
-		return -1;
-
-	return pdev->bus->number - instance->bus0;
-}
-
-/* This is exported, as some devices need to access the MFD registers */
-struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev)
-{
-	return sta2x11_pdev_to_instance(pdev);
-}
-EXPORT_SYMBOL(sta2x11_get_instance);
-
-/* At setup time, we use our own ops if the device is a ConneXt one */
-static void sta2x11_setup_pdev(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev);
-
-	if (!instance) /* either a sta2x11 bridge or another ST device */
-		return;
-
-	/* We must enable all devices as master, for audio DMA to work */
-	pci_set_master(pdev);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_setup_pdev);
-
-/*
- * At boot we must set up the mappings for the pcie-to-amba bridge.
- * It involves device access, and the same happens at suspend/resume time
- */
-
-#define AHB_MAPB		0xCA4
-#define AHB_CRW(i)		(AHB_MAPB + 0  + (i) * 0x10)
-#define AHB_CRW_SZMASK			0xfffffc00UL
-#define AHB_CRW_ENABLE			(1 << 0)
-#define AHB_CRW_WTYPE_MEM		(2 << 1)
-#define AHB_CRW_ROE			(1UL << 3)	/* Relax Order Ena */
-#define AHB_CRW_NSE			(1UL << 4)	/* No Snoop Enable */
-#define AHB_BASE(i)		(AHB_MAPB + 4  + (i) * 0x10)
-#define AHB_PEXLBASE(i)		(AHB_MAPB + 8  + (i) * 0x10)
-#define AHB_PEXHBASE(i)		(AHB_MAPB + 12 + (i) * 0x10)
-
-/* At probe time, enable mapping for each endpoint, using the pdev */
-static void sta2x11_map_ep(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev);
-	struct device *dev = &pdev->dev;
-	u32 amba_base, max_amba_addr;
-	int i, ret;
-
-	if (!instance)
-		return;
-
-	pci_read_config_dword(pdev, AHB_BASE(0), &amba_base);
-	max_amba_addr = amba_base + STA2X11_AMBA_SIZE - 1;
-
-	ret = dma_direct_set_offset(dev, 0, amba_base, STA2X11_AMBA_SIZE);
-	if (ret)
-		dev_err(dev, "sta2x11: could not set DMA offset\n");
-
-	dev->bus_dma_limit = max_amba_addr;
-	dma_set_mask_and_coherent(&pdev->dev, max_amba_addr);
-
-	/* Configure AHB mapping */
-	pci_write_config_dword(pdev, AHB_PEXLBASE(0), 0);
-	pci_write_config_dword(pdev, AHB_PEXHBASE(0), 0);
-	pci_write_config_dword(pdev, AHB_CRW(0), STA2X11_AMBA_SIZE |
-			       AHB_CRW_WTYPE_MEM | AHB_CRW_ENABLE);
-
-	/* Disable all the other windows */
-	for (i = 1; i < STA2X11_NR_FUNCS; i++)
-		pci_write_config_dword(pdev, AHB_CRW(i), 0);
-
-	dev_info(&pdev->dev,
-		 "sta2x11: Map EP %i: AMBA address %#8x-%#8x\n",
-		 sta2x11_pdev_to_ep(pdev), amba_base, max_amba_addr);
-}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_map_ep);
-
-#ifdef CONFIG_PM /* Some register values must be saved and restored */
-
-static struct sta2x11_mapping *sta2x11_pdev_to_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_instance *instance;
-	int ep;
-
-	instance = sta2x11_pdev_to_instance(pdev);
-	if (!instance)
-		return NULL;
-	ep = sta2x11_pdev_to_ep(pdev);
-	return instance->map + ep;
-}
-
-static void suspend_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
-	int i;
-
-	if (!map)
-		return;
-
-	if (map->is_suspended)
-		return;
-	map->is_suspended = 1;
-
-	/* Save all window configs */
-	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
-		struct sta2x11_ahb_regs *regs = map->regs + i;
-
-		pci_read_config_dword(pdev, AHB_BASE(i), &regs->base);
-		pci_read_config_dword(pdev, AHB_PEXLBASE(i), &regs->pexlbase);
-		pci_read_config_dword(pdev, AHB_PEXHBASE(i), &regs->pexhbase);
-		pci_read_config_dword(pdev, AHB_CRW(i), &regs->crw);
-	}
-}
-DECLARE_PCI_FIXUP_SUSPEND(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, suspend_mapping);
-
-static void resume_mapping(struct pci_dev *pdev)
-{
-	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
-	int i;
-
-	if (!map)
-		return;
-
-
-	if (!map->is_suspended)
-		goto out;
-	map->is_suspended = 0;
-
-	/* Restore all window configs */
-	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
-		struct sta2x11_ahb_regs *regs = map->regs + i;
-
-		pci_write_config_dword(pdev, AHB_BASE(i), regs->base);
-		pci_write_config_dword(pdev, AHB_PEXLBASE(i), regs->pexlbase);
-		pci_write_config_dword(pdev, AHB_PEXHBASE(i), regs->pexhbase);
-		pci_write_config_dword(pdev, AHB_CRW(i), regs->crw);
-	}
-out:
-	pci_set_master(pdev); /* Like at boot, enable master on all devices */
-}
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, resume_mapping);
-
-#endif /* CONFIG_PM */

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v3 10/10] x86: only allow EISA for 32-bit
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (8 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 09/10] x86: remove old STA2x11 support Arnd Bergmann
@ 2025-02-26 21:37 ` Arnd Bergmann
  2025-02-27 10:42   ` [tip: x86/cpu] x86/platform: Only allow CONFIG_EISA " tip-bot2 for Arnd Bergmann
  2025-02-27 10:34 ` [PATCH v3 00/10] x86: 32-bit cleanups Ingo Molnar
  10 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2025-02-26 21:37 UTC (permalink / raw)
  To: linux-kernel, x86
  Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, H. Peter Anvin, Linus Torvalds, Andy Shevchenko,
	Matthew Wilcox, Maciej W. Rozycki

From: Arnd Bergmann <arnd@arndb.de>

The CONFIG_EISA menu was cleaned up in 2018, but this inadvertently
brought the option back on 64-bit machines: ISA remains guarded by
a CONFIG_X86_32 check, but EISA no longer depends on ISA.

The last Intel machines ith EISA support used a 82375EB PCI/EISA bridge
from 1993 that could be paired with the 440FX chipset on early Pentium-II
CPUs, long before the first x86-64 products.

Fixes: 6630a8e50105 ("eisa: consolidate EISA Kconfig entry in drivers/eisa")
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 14dd7b5abd5d..f84a9e5dda20 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -232,7 +232,7 @@ config X86
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI	if X86_64
 	select HAVE_EBPF_JIT
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
-	select HAVE_EISA
+	select HAVE_EISA			if X86_32
 	select HAVE_EXIT_THREAD
 	select HAVE_GUP_FAST
 	select HAVE_FENTRY			if X86_64 || DYNAMIC_FTRACE
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [tip: x86/cpu] x86/platform: Only allow CONFIG_EISA for 32-bit
  2025-02-26 21:37 ` [PATCH v3 10/10] x86: only allow EISA for 32-bit Arnd Bergmann
@ 2025-02-27 10:42   ` tip-bot2 for Arnd Bergmann
  0 siblings, 0 replies; 29+ messages in thread
From: tip-bot2 for Arnd Bergmann @ 2025-02-27 10:42 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Arnd Bergmann, Ingo Molnar, Linus Torvalds, x86, linux-kernel

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     976ba8da2f3c2f1e997f4f620da83ae65c0e3728
Gitweb:        https://git.kernel.org/tip/976ba8da2f3c2f1e997f4f620da83ae65c0e3728
Author:        Arnd Bergmann <arnd@arndb.de>
AuthorDate:    Wed, 26 Feb 2025 22:37:14 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 27 Feb 2025 11:22:16 +01:00

x86/platform: Only allow CONFIG_EISA for 32-bit

The CONFIG_EISA menu was cleaned up in 2018, but this inadvertently
brought the option back on 64-bit machines: ISA remains guarded by
a CONFIG_X86_32 check, but EISA no longer depends on ISA.

The last Intel machines ith EISA support used a 82375EB PCI/EISA bridge
from 1993 that could be paired with the 440FX chipset on early Pentium-II
CPUs, long before the first x86-64 products.

Fixes: 6630a8e50105 ("eisa: consolidate EISA Kconfig entry in drivers/eisa")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250226213714.4040853-11-arnd@kernel.org
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 383b145..aa90f03 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -233,7 +233,7 @@ config X86
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI	if X86_64
 	select HAVE_EBPF_JIT
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
-	select HAVE_EISA
+	select HAVE_EISA			if X86_32
 	select HAVE_EXIT_THREAD
 	select HAVE_GUP_FAST
 	select HAVE_FENTRY			if X86_64 || DYNAMIC_FTRACE

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 00/10] x86: 32-bit cleanups
  2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
                   ` (9 preceding siblings ...)
  2025-02-26 21:37 ` [PATCH v3 10/10] x86: only allow EISA for 32-bit Arnd Bergmann
@ 2025-02-27 10:34 ` Ingo Molnar
  2025-02-27 14:08   ` Andy Shevchenko
  10 siblings, 1 reply; 29+ messages in thread
From: Ingo Molnar @ 2025-02-27 10:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-kernel, x86, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, H. Peter Anvin, Linus Torvalds,
	Andy Shevchenko, Matthew Wilcox


* Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> While looking at 32-bit arm cleanups, I came across some related topics
> on x86 and ended up making a series for those as well.
> 
> Primarily this is about running 32-bit kernels on 64-bit hardware,
> which usually works but should probably be discouraged more clearly by
> only providing support for features that are used on real 32-bit hardware:
> 
> I found only a few 2003-era high-end servers (HP DL740 and DL760 G2)
> that were the only possible remaining uses of HIGHMEM64G and BIGSMP after
> the removal of 32-bit NUMA machines in 2014. Similarly, there is only
> one generation of hardware with support for VT-x.  All these features
> can be removed without hurting users.
> 
> In the CPU selection, building a 32-bit kernel optimized for AMD K8
> or Intel Core2 is anachronistic, so instead only 32-bit CPU types need
> to be offered as optimization targets. The "generic" target on 64-bit
> turned out to be slightly broken, so I included a fix for that as well.
> 
> Changes since v2:
> 
>  - Add a patch for EISA
>  - keep PHYS_ADDR_T_64BIT enabled for PAE kernels
>  - drop the Kconfig.platforms and CONFIG_X86_64_NATIVE patches for now
>  - improve changelog texts
> 
> Changes since v1:
> 
>  - Don't include patch to drop 32-bit KVM support for now
>  - Drop patch for 64-bit Silverlake support
>  - Drop 64-bit ISA level selection, only fix default
>  - Rework MID patch based on comments
>  - Add a patch to reorganize platform selection
>  - Add a patch to add -march=native compilation
> 
> 
> Arnd Bergmann (10):
>   x86/Kconfig: Geode CPU has cmpxchg8b
>   x86: drop 32-bit "bigsmp" machine support
>   x86: rework CONFIG_GENERIC_CPU compiler flags
>   x86: drop configuration options for early 64-bit CPUs
>   x86: remove HIGHMEM64G support
>   x86: drop SWIOTLB for PAE
>   x86: drop support for CONFIG_HIGHPTE
>   x86: document X86_INTEL_MID as 64-bit-only
>   x86: remove old STA2x11 support
>   x86: only allow EISA for 32-bit
> 
>  Documentation/admin-guide/kdump/kdump.rst     |   4 -
>  .../admin-guide/kernel-parameters.txt         |  11 -
>  Documentation/arch/x86/usb-legacy-support.rst |  11 +-
>  arch/x86/Kconfig                              | 156 +++---------
>  arch/x86/Kconfig.cpu                          |  97 ++------
>  arch/x86/Makefile                             |  16 +-
>  arch/x86/Makefile_32.cpu                      |   5 +-
>  arch/x86/configs/xen.config                   |   2 -
>  arch/x86/include/asm/page_32_types.h          |   4 +-
>  arch/x86/include/asm/pgalloc.h                |   5 -
>  arch/x86/include/asm/sta2x11.h                |  13 -
>  arch/x86/include/asm/vermagic.h               |   4 -
>  arch/x86/kernel/apic/Makefile                 |   3 -
>  arch/x86/kernel/apic/apic.c                   |   3 -
>  arch/x86/kernel/apic/bigsmp_32.c              | 105 --------
>  arch/x86/kernel/apic/local.h                  |  13 -
>  arch/x86/kernel/apic/probe_32.c               |  29 ---
>  arch/x86/mm/init_32.c                         |   9 +-
>  arch/x86/mm/pgtable.c                         |  27 +-
>  arch/x86/pci/Makefile                         |   2 -
>  arch/x86/pci/sta2x11-fixup.c                  | 233 ------------------
>  drivers/misc/mei/Kconfig                      |   2 +-
>  22 files changed, 66 insertions(+), 688 deletions(-)

Sweet! I have applied your series to tip:x86/cpu with some minor tweaks 
and a conflict resolution for pending work in x86/mm. Let's see if 
anyone complains about the removal of these obsolete features.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v3 00/10] x86: 32-bit cleanups
  2025-02-27 10:34 ` [PATCH v3 00/10] x86: 32-bit cleanups Ingo Molnar
@ 2025-02-27 14:08   ` Andy Shevchenko
  0 siblings, 0 replies; 29+ messages in thread
From: Andy Shevchenko @ 2025-02-27 14:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Arnd Bergmann, linux-kernel, x86, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
	Linus Torvalds, Andy Shevchenko, Matthew Wilcox

On Thu, Feb 27, 2025 at 12:34 PM Ingo Molnar <mingo@kernel.org> wrote:
> * Arnd Bergmann <arnd@kernel.org> wrote:

> > While looking at 32-bit arm cleanups, I came across some related topics
> > on x86 and ended up making a series for those as well.
> >
> > Primarily this is about running 32-bit kernels on 64-bit hardware,
> > which usually works but should probably be discouraged more clearly by
> > only providing support for features that are used on real 32-bit hardware:
> >
> > I found only a few 2003-era high-end servers (HP DL740 and DL760 G2)
> > that were the only possible remaining uses of HIGHMEM64G and BIGSMP after
> > the removal of 32-bit NUMA machines in 2014. Similarly, there is only
> > one generation of hardware with support for VT-x.  All these features
> > can be removed without hurting users.
> >
> > In the CPU selection, building a 32-bit kernel optimized for AMD K8
> > or Intel Core2 is anachronistic, so instead only 32-bit CPU types need
> > to be offered as optimization targets. The "generic" target on 64-bit
> > turned out to be slightly broken, so I included a fix for that as well.


> Sweet! I have applied your series to tip:x86/cpu with some minor tweaks
> and a conflict resolution for pending work in x86/mm. Let's see if
> anyone complains about the removal of these obsolete features.

A bit of offtopic here since it seems I have not noticed any activity
in your header dependency clean up series are you planning to rebase
it at some point? And what is the status in general?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2025-02-28 18:40 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-26 21:37 [PATCH v3 00/10] x86: 32-bit cleanups Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 01/10] x86/Kconfig: Geode CPU has cmpxchg8b Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/Kconfig: Add cmpxchg8b support back to Geode CPUs tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 02/10] x86: drop 32-bit "bigsmp" machine support Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/smp: Drop " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 03/10] x86: rework CONFIG_GENERIC_CPU compiler flags Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/build: Rework " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 04/10] x86: drop configuration options for early 64-bit CPUs Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/cpu: Drop " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 05/10] x86: remove HIGHMEM64G support Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Remove CONFIG_HIGHMEM64G support tip-bot2 for Arnd Bergmann
2025-02-27 15:41   ` [PATCH v3 05/10] x86: remove HIGHMEM64G support H. Peter Anvin
2025-02-27 16:51     ` Linus Torvalds
2025-02-28  1:48       ` H. Peter Anvin
2025-02-28 10:09       ` Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 06/10] x86: drop SWIOTLB for PAE Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Drop CONFIG_SWIOTLB " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 07/10] x86: drop support for CONFIG_HIGHPTE Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/mm: Drop " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 08/10] x86: document X86_INTEL_MID as 64-bit-only Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/cpu: Document CONFIG_X86_INTEL_MID " tip-bot2 for Arnd Bergmann
2025-02-28 16:20   ` [PATCH v3 08/10] x86: document X86_INTEL_MID " Ferry Toth
2025-02-28 18:40     ` Andy Shevchenko
2025-02-26 21:37 ` [PATCH v3 09/10] x86: remove old STA2x11 support Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/pci: Remove " tip-bot2 for Arnd Bergmann
2025-02-26 21:37 ` [PATCH v3 10/10] x86: only allow EISA for 32-bit Arnd Bergmann
2025-02-27 10:42   ` [tip: x86/cpu] x86/platform: Only allow CONFIG_EISA " tip-bot2 for Arnd Bergmann
2025-02-27 10:34 ` [PATCH v3 00/10] x86: 32-bit cleanups Ingo Molnar
2025-02-27 14:08   ` Andy Shevchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox