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