On Tue, 23 Jun 2026 15:50:41 +0800
fanhuang <FangSheng.Huang@amd.com> wrote:
> This series adds a TYPE_MEMORY_DEVICE subclass `sp-mem` for boot-time
> SOFT_RESERVED guest memory, following the direction from the v7
> thread [1] and the v8 / v9 / v10 / v11 / v12 / v13 reviews
> [2][3][4][5][6][7].
review is done at this point,
I guess Michael will take it via his tree.
>
> 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 SPM 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 series introduces a new TYPE_MEMORY_DEVICE subclass `sp-mem`.
> Each instance binds one host memory backend to a single NUMA
> proximity domain and is boot-time only; placement, mapped-state
> enforcement, and QMP introspection come from the existing
> memory-device framework.
>
> Testing
> -------
>
> Verified end-to-end on q35 + KVM, with both SeaBIOS and OVMF, for:
>
> - single sp-mem instance
> - two sp-mem instances on different NUMA nodes
>
> Guest observations: /proc/iomem shows one SOFT_RESERVED entry per
> sp-mem device, dmesg SRAT parsing reports the matching
> memory_affinity entries with correct PXM, and the umbrella
> HOTPLUGGABLE entry covers the remaining hotplug-memory window
> without overlapping the sp-mem ranges.
>
> In-tree coverage: a bios-tables-test case validates the SRAT
> partition for two sp-mem devices on distinct nodes, and an e820
> fw_cfg test checks the SOFT_RESERVED range.
>
> Changes since v13
> -----------------
>
> - qapi: note that SpMemDeviceInfo's @size is in bytes.
> - pc: fix the indentation of the pc_sp_mem_plug() continuation line.
> - Collected the Reviewed-by / Acked-by tags from the v13 review.
>
> 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/
> v8: https://lore.kernel.org/qemu-devel/20260527074215.229119-1-FangSheng.Huang@amd.com/
> v9: https://lore.kernel.org/qemu-devel/20260602084447.1100554-1-FangSheng.Huang@amd.com/
> v10: https://lore.kernel.org/qemu-devel/20260605104609.1739911-1-FangSheng.Huang@amd.com/
> v11: https://lore.kernel.org/qemu-devel/20260611100637.2460507-1-FangSheng.Huang@amd.com/
> v12: https://lore.kernel.org/qemu-devel/20260616090808.3047939-1-FangSheng.Huang@amd.com/
> v13: https://lore.kernel.org/qemu-devel/20260619111136.3481329-1-FangSheng.Huang@amd.com/
>
> [1] v7 thread closeout:
> https://lore.kernel.org/qemu-devel/666a7ba1-5d3a-4732-b872-0d9fb2fe8461@amd.com/
> [2] v8 review:
> https://lore.kernel.org/qemu-devel/20260601105057.2d764e55@imammedo/
> [3] v9 review:
> https://lore.kernel.org/qemu-devel/20260602084447.1100554-1-FangSheng.Huang@amd.com/T/
> [4] v10 review:
> https://lore.kernel.org/qemu-devel/20260605104609.1739911-1-FangSheng.Huang@amd.com/T/
> [5] v11 review:
> https://lore.kernel.org/qemu-devel/20260611100637.2460507-1-FangSheng.Huang@amd.com/T/
> [6] v12 review:
> https://lore.kernel.org/qemu-devel/20260616090808.3047939-1-FangSheng.Huang@amd.com/T/
> [7] v13 review:
> https://lore.kernel.org/qemu-devel/20260619111136.3481329-1-FangSheng.Huang@amd.com/T/
>
> fanhuang (10):
> hw/mem: add sp-mem device for Specific Purpose Memory
> qapi, hmp: introspection for the sp-mem device
> i386/acpi-build: partition device_memory SRAT umbrella for sp-mem
> hw/i386: hook sp-mem into the pc machine plug path
> MAINTAINERS: cover sp-mem under Memory devices, add R: tag
> tests/acpi: add empty expected blobs for sp-mem SRAT test
> tests/acpi: add bios-tables-test case for sp-mem
> tests/acpi: generate expected blobs for sp-mem SRAT test
> tests/qtest: add e820 fw_cfg test
> tests/qtest: cover sp-mem SOFT_RESERVED e820 entry
>
> MAINTAINERS | 3 +
> qapi/machine.json | 43 +++++++++-
> hw/i386/e820_memory_layout.h | 11 +--
> include/hw/mem/sp-mem.h | 33 ++++++++
> hw/core/machine-hmp-cmds.c | 11 +++
> hw/i386/acpi-build.c | 96 ++++++++++++++++++++-
> hw/i386/pc.c | 36 ++++++++
> hw/mem/sp-mem.c | 128 ++++++++++++++++++++++++++++
> tests/qtest/bios-tables-test.c | 21 +++++
> tests/qtest/e820-test.c | 129 +++++++++++++++++++++++++++++
> hw/i386/Kconfig | 2 +
> hw/mem/Kconfig | 4 +
> hw/mem/meson.build | 1 +
> tests/data/acpi/x86/q35/DSDT.spmem | Bin 0 -> 9910 bytes
> tests/data/acpi/x86/q35/SRAT.spmem | Bin 0 -> 384 bytes
> tests/qtest/meson.build | 1 +
> 16 files changed, 508 insertions(+), 11 deletions(-)
> create mode 100644 include/hw/mem/sp-mem.h
> create mode 100644 hw/mem/sp-mem.c
> create mode 100644 tests/qtest/e820-test.c
> create mode 100644 tests/data/acpi/x86/q35/DSDT.spmem
> create mode 100644 tests/data/acpi/x86/q35/SRAT.spmem
>
>
> base-commit: b83371668192a705b878e909c5ae9c1233cbd5fb