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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b767e107-9000-49fb-a93d-40192e1f170e@amd.com>
Date: Thu, 11 Dec 2025 16:07:34 -0600
From: "Pratik R. Sampat" <prsampat@....com>
To: Kiryl Shutsemau <kas@...nel.org>
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 12/11/25 9:00 AM, Kiryl Shutsemau wrote:
> 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.

Not an EFI expert by a long shot, but seems so.
EFI_MEMORY_HOT_PLUGGABLE attribute does exist for hot-removable regions
of memory that must not be used for allocation during the boot context.
However, I am unclear if this in principle is also supposed to span
the entire range or just the cold-plugged regions of memory.

> 
> 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.
> 

Absolutely, accepting memory as soon as it's added is easy.
Benchmarking it's effects may be a little tricky since unlike measuring
boot-time in eager vs lazy we may have to find representative workloads
to measure how much overheads accepting memory up-front adds.

Thanks
--Pratik