| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <572DCA31-1CCA-45FB-ADCD-29C24A527437@zytor.com>
Date: Thu, 27 Feb 2025 07:41:26 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Arnd Bergmann <arnd@...nel.org>, linux-kernel@...r.kernel.org,
x86@...nel.org
CC: Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Shevchenko <andy@...nel.org>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support
On February 26, 2025 1:37:09 PM PST, Arnd Bergmann <arnd@...nel.org> wrote:
>From: Arnd Bergmann <arnd@...db.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@...db.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.
Powered by blists - more mailing lists