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/[email protected]/ v2: https://lore.kernel.org/qemu-devel/[email protected]/ v3: https://lore.kernel.org/qemu-devel/[email protected]/ v4: https://lore.kernel.org/qemu-devel/[email protected]/ v5: https://lore.kernel.org/qemu-devel/[email protected]/ v6: https://lore.kernel.org/qemu-devel/[email protected]/ v7: https://lore.kernel.org/qemu-devel/[email protected]/ [1] v7 thread above, closed out by: https://lore.kernel.org/qemu-devel/[email protected]/ 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
