Re: [PATCH v12 0/4] hw/mem: add sp-mem device for Specific Purpose Memory

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 16 Jun 2026 17:08:04 +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 reviews [2][3][4][5].

review is done, modulo cosmetic patch restructuring and missing tests
LGTM.

as for adding duplication, I'm expecting cleanup/consolidation
refactoring on top, that I've asked for in earlier reviews. 

> 
> 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.
> 
> Changes since v11
> -----------------
> 
>   - Drop the unneeded memory-device.h and system/hostmem.h includes
>     from sp-mem.h (HostMemoryBackend is forward-declared).
>   - Use SP_MEM_MEMDEV_PROP in sp_mem_get_memory_region()'s error
>     message, matching realize().
>   - Move the .unmigratable comment next to the field it documents.
> 
> All v11 patch-1 review comments from Philippe; patches 2-4 unchanged.
> Patch 4 (MAINTAINERS) retains the Acked-by from Igor and David.
> 
> 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/
> 
>   [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/
> 
> fanhuang (4):
>   hw/mem: add sp-mem device for Specific Purpose Memory
>   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
> 
>  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              | 136 +++++++++++++++++++++++++++++++++++
>  hw/i386/Kconfig              |   2 +
>  hw/mem/Kconfig               |   4 ++
>  hw/mem/meson.build           |   1 +
>  11 files changed, 365 insertions(+), 11 deletions(-)
>  create mode 100644 include/hw/mem/sp-mem.h
>  create mode 100644 hw/mem/sp-mem.c
> 
> 
> base-commit: 2f28d34ea0aead9830478cd1d3d0dd9d9191d82e
> --
> 2.34.1
>