Re: [PATCH v2] numa: add 'spm' option for Specific Purpose Memory

["Huang, FangSheng (Jerry)" <FangSheng.Huang@amd.com>]

On 10/21/2025 4:03 AM, David Hildenbrand wrote:
> On 20.10.25 12:15, Jonathan Cameron wrote:
>> On Mon, 20 Oct 2025 17:07:00 +0800
>> fanhuang <FangSheng.Huang@amd.com> wrote:
>>
>>> Hi David and Igor,
>>>
>>> I apologize for the delayed response. Thank you very much for your 
>>> thoughtful
>>> questions and feedback on the SPM patch series.
>>>
>>> Before addressing your questions, I'd like to briefly mention what 
>>> the new
>>> QEMU patch series additionally resolves:
>>>
>>> 1. **Corrected SPM terminology**: Fixed the description error from 
>>> the previous
>>>     version. The correct acronym is "Specific Purpose Memory" (not 
>>> "special
>>>     purpose memory" as previously stated).
>>>
>>> 2. **Fixed overlapping E820 entries**: Updated the implementation to 
>>> properly
>>>     handle overlapping E820 RAM entries before adding E820_SOFT_RESERVED
>>>     regions.
>>>
>>>     The previous implementation created overlapping E820 entries by 
>>> first adding
>>>     a large E820_RAM entry covering the entire above-4GB memory 
>>> range, then
>>>     adding E820_SOFT_RESERVED entries for SPM regions that overlapped 
>>> with the
>>>     RAM entry. This violated the E820 specification and caused OVMF/UEFI
>>>     firmware to receive conflicting memory type information for the same
>>>     physical addresses.
>>>
>>>     The new implementation processes SPM regions first to identify 
>>> reserved
>>>     areas, then adds RAM entries around the SPM regions, generating a 
>>> clean,
>>>     non-overlapping E820 map.
>>
>> I'm definitely in favor of this support for testing purposes as well as
>> for the GPU cases you describe.
> 
> Thanks for taking a look!
> 
>>
>> Given I took your brief comment on hotplug and expanded on it +CC David
>> and Oscar.
>>
>>>
>>> Now, regarding your questions:
>>>
>>> ========================================================================
>>> Why SPM Must Be Boot Memory
>>> ========================================================================
>>>
>>> SPM cannot be implemented as hotplug memory (DIMM/NVDIMM) because:
>>>
>>> The primary goal of SPM is to ensure that memory is managed by guest
>>> device drivers, not the guest OS. This requires boot-time discovery
>>> for three key reasons:
>>>
>>> 1. SPM regions must appear in the E820 memory map as 
>>> `E820_SOFT_RESERVED`
>>>     during firmware initialization, before the OS starts.
>>>
>>> 2. Hotplug memory is integrated into kernel memory management, making
>>>     it unavailable for device-specific use.
>>
>> This is only sort of true and perhaps reflects support in the kernel 
>> for ACPI
>> features being missing as no one has yet been interested in them.
>> See 9.11.3 Hot-pluggable Memory Description Illustrated in the 6.6 
>> ACPI spec.
>> That has an example where the EFI_MEMORY_SP bit is provided.
>> I had a dig around and for now ACPICA / kernel doesn't seem to put 
>> that alongside
>> write_protect and the other bits that IIUC come from the same field.
>> It would be relatively easy to pipe that through and potentially add 
>> handling
>> in the memory hotplug path to allow for drivers to pick these regions up
>> (which boils down I think to making them visible in some way but doing 
>> nothing
>> else with them)
> 
> Considering something like DIMMs, one challenge is also that hotplugged 
> memory in QEMU is never advertised in e820 (we only indicate the 
> hotpluggable region), which is different to real hardware but let's us 
> stop the early kernel that is booting up from considering these areas 
> "initial memory" and effectively turning them hot-unpluggable in the 
> default case.
> 
> Then, the question is what happens when someone plugs such a DIMM, 
> unplugs it, and plugs something else in there that's not supposed to be SP.
> 
> I assume that's all solvable, just want to point out that the default 
> memory hotplug path in QEMU is not really suitable for that right now I 
> think.
> 
>>
>> Other path would be to use a discoverable path such as emulating CXL 
>> memory.
>> Hotplug of that would work fine from point of view of coming up as 
>> driver managed
>> SPM style (the flag is in runtime data provided by the device). It 
>> would however
>> look different to the firmware managed approach you are using in the 
>> host.
> 
> Right.
> 
Hi David and Jonathan,

Thank you both for the support and for the forward-looking
perspective on potential future approaches like EFI_MEMORY_SP and CXL
emulation.

I appreciate the constructive technical discussion from both of you. 
Please let me know if there's anything else I should clarify about the 
implementation.

Best regards,
Jerry Huang