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

[Jonathan Cameron via <qemu-devel@nongnu.org>]

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.

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)

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.

All I want to draw attention to is that there are other ways of doing this
that might be relevant in future, but don't work for what you need to do today.
So don't see this an objection to this specific bit of work!

Thanks,

Jonathan