This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` for boot-time
SOFT_RESERVED guest memory, following the direction from the v7 thread [1].
Background
----------
This series targets coherent CPU + accelerator shared-address-space
systems, where the accelerator's HBM is not a device-private framebuffer
behind a PCIe BAR but a tier of host system memory: visible to the CPU
in the platform physical address space, shared coherently with the
accelerator over the platform fabric, and bound to a NUMA proximity
domain set by platform firmware at boot fabric training.
For such a region to function correctly in the guest, two things must
hold simultaneously: the CPU memory subsystem has to see it in the
system memory map (so the CPU side can address it), and it has to be
reserved exclusively for the accelerator's driver (so the kernel's
general allocator does not hand HBM pages to unrelated workloads). The
SOFT_RESERVED memory type in E820 plus a matching SRAT memory-affinity
entry is the mechanism that delivers both: a firmware-produced topology
that the CPU memory subsystem honors and the accelerator's driver
consumes for its own range.
Approach
--------
The patch adds a new TYPE_MEMORY_DEVICE subclass `spm-memory`. Each
instance binds one host memory backend to a single NUMA proximity
domain and is boot-time only; placement, hotplug rejection, and QMP
introspection come from the existing memory-device framework. The
device emits one E820 SOFT_RESERVED entry per instance at
machine_done and one SRAT memory-affinity entry per instance at
acpi-build, the latter flagged ENABLED only.
The device_memory SRAT umbrella entry in hw/i386/acpi-build.c is
restructured into a per-kind partition: for each plugged
TYPE_SPM_MEMORY device the partition emits an ENABLED entry at the
device's proximity_domain, and the remaining sub-ranges (gaps between
SPM devices, leading and trailing padding, and ranges occupied by
non-SPM memory devices) are emitted as HOTPLUGGABLE | ENABLED entries
at the placeholder PXM (nb_numa_nodes - 1).
No firmware-side change is required: the existing OVMF and SeaBIOS
handling for E820 SOFT_RESERVED and ACPI SRAT covers the guest-facing
contract.
Testing
-------
Verified end-to-end on SeaBIOS and OVMF, q35 + KVM, for:
- single spm-memory instance (natural placement and explicit addr=)
- two spm-memory instances on different NUMA nodes (tight pack and
with inter-device gap)
- one spm-memory + one pc-dimm on different NUMA nodes
Guest observations: /proc/iomem shows SOFT_RESERVED at the expected
addresses, dmesg SRAT parsing finds the per-device memory_affinity
entries with correct PXM.
Previous versions
-----------------
v1: https://lore.kernel.org/qemu-devel/20250924103324.2074819-1-FangSheng.Huang@amd.com/
v2: https://lore.kernel.org/qemu-devel/20251020090701.4036748-1-FangSheng.Huang@amd.com/
v3: https://lore.kernel.org/qemu-devel/20251208105137.2058928-1-FangSheng.Huang@amd.com/
v4: https://lore.kernel.org/qemu-devel/20251209093841.2250527-1-FangSheng.Huang@amd.com/
v5: https://lore.kernel.org/qemu-devel/20260123024312.1601732-1-FangSheng.Huang@amd.com/
v6: https://lore.kernel.org/qemu-devel/20260226105023.256568-1-FangSheng.Huang@amd.com/
v7: https://lore.kernel.org/qemu-devel/20260306082735.1106690-1-FangSheng.Huang@amd.com/
[1] v7 thread above, closed out by:
https://lore.kernel.org/qemu-devel/666a7ba1-5d3a-4732-b872-0d9fb2fe8461@amd.com/
fanhuang (1):
hw/mem: add spm-memory device for Specific Purpose Memory
MAINTAINERS | 2 +
hw/i386/Kconfig | 2 +
hw/i386/acpi-build.c | 105 ++++++++++++--
hw/i386/e820_memory_layout.h | 11 +-
hw/mem/Kconfig | 4 +
hw/mem/meson.build | 1 +
hw/mem/spm-memory.c | 269 +++++++++++++++++++++++++++++++++++
include/hw/mem/spm-memory.h | 43 ++++++
qapi/machine.json | 43 +++++-
9 files changed, 459 insertions(+), 21 deletions(-)
create mode 100644 hw/mem/spm-memory.c
create mode 100644 include/hw/mem/spm-memory.h
--
2.34.1