linux-kernel - Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

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 for Android: free password hash cracker in your pocket

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

Message-ID: <uc6yz23havsg2cdgtk3fgku7xr4gj2ykse7lxitcs4eh2fw4vo@hyavdm3ovdfh>
Date: Thu, 11 Dec 2025 15:00:39 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: "Pratik R. Sampat" <prsampat@....com>
Cc: "David Hildenbrand (Red Hat)" <david@...nel.org>, linux-mm@...ck.org, 
	linux-coco@...ts.linux.dev, linux-efi@...r.kernel.org, x86@...nel.org, 
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, ardb@...nel.org, akpm@...ux-foundation.org, osalvador@...e.de, 
	thomas.lendacky@....com, michael.roth@....com
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

On Tue, Dec 09, 2025 at 03:36:09PM -0600, Pratik R. Sampat wrote:
> > Agreed, I think Kiryl was hinting at pre-allocated bitmaps as well.
> > 
> > Since, the overhead to do this upfront is fairly minimal, that should
> > certainly simplify things and have very little to no meddling with the
> > original EFI struct.
> > 
> 
> Taking another look at this suggestion, I think there may be more to it
> than I previously thought. Parsing e820 tables to know what the range
> are for allocating the bitmap to cover hotplug may be difficult. For e.g
> 
> [ 0.000000] efi: mem110: [Unaccepted <snip>]
> range=[0x0000000100000000-0x000000017fffffff] (2048MB)
> [ 0.000000] efi: mem111: [Reserved   <snip>]
> range=[0x000000fd00000000-0x000000ffffffffff] (12288MB)
> 
> Parsing of the ACPI SRAT seems to be the one that gives us useful ranges
> to base the upfront bitmap allocation on. e.g.
> ...
> [    0.018357] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x17fffffff]
> [    0.018781] ACPI: SRAT: Node 0 PXM 0 [mem 0x180000000-0x2ffffffff]
> hotplug
> This is also where max_possible_pfn gets updated to reflect this range.

Do I understand correctly that EFI memory map doesn't mention hot plug
range at all, but SRAT does?

That's a mess. I thought, all hotpluggable range supposed to be declared
in the memory map.

I wounder if it is what BIOS provides, or is it result of EFI memmap
cleanup by kernel? I see we are doing bunch of them, like in
efi_remove_e820_mmio().

> One potential solution could be to parse the SRAT during unaccepted
> memory bitmap allocation in the EFI stub. However, this would fragment
> the implementation by duplicating the SRAT parsing. Alternatively, we
> could keep the current approach of dynamically allocating the bitmap on
> hotplug or I could also replace the entire memblock_reserved unaccepted
> table like Kiryl suggested if we must absolutely avoid changing the
> unaccepted structure?

Other possible option would be to accept all memory on hotplug and don't
touch the bitmap at all. It might be not that bad: it doesn't block boot.
We can think of a better solution later, if needed.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov