linux-kernel - Re: [PATCH 05/11] x86: remove HIGHMEM64G support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <00e344d7-8d2f-41d3-8c6a-1a828ee95967@app.fastmail.com>
Date: Wed, 04 Dec 2024 14:43:28 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Brian Gerst" <brgerst@...il.com>, "Arnd Bergmann" <arnd@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Andy Shevchenko" <andy@...nel.org>, "Matthew Wilcox" <willy@...radead.org>,
 "Sean Christopherson" <seanjc@...gle.com>,
 "Davide Ciminaghi" <ciminaghi@...dd.com>,
 "Paolo Bonzini" <pbonzini@...hat.com>, kvm@...r.kernel.org
Subject: Re: [PATCH 05/11] x86: remove HIGHMEM64G support

On Wed, Dec 4, 2024, at 14:29, Brian Gerst wrote:
> On Wed, Dec 4, 2024 at 5:34 AM Arnd Bergmann <arnd@...nel.org> wrote:
>>
>>  - 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.
>>
>> Removing this also drops the need for PHYS_ADDR_T_64BIT and SWIOTLB.
>> PAE mode is still required to get access to the 'NX' bit on Atom
>> 'Pentium M' and 'Core Duo' CPUs.
>
> 8GB of memory is still useful for 32-bit guest VMs.

Can you give some more background on this?

It's clear that one can run a virtual machine this way and it
currently works, but are you able to construct a case where this
is a good idea, compared to running the same userspace with a
64-bit kernel?

>From what I can tell, any practical workload that requires
8GB of total RAM will likely run into either the lowmem
limits or into virtual addressig limits, in addition to the
problems of 32-bit kernels being generally worse than 64-bit
ones in terms of performance, features and testing.

      Arnd