On 20.10.25 12:15, Jonathan Cameron wrote:
On Mon, 20 Oct 2025 17:07:00 +0800 fanhuang <[email protected]> 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. -- Cheers David / dhildenb
