MAINTAINERS | 2 + hw/i386/Kconfig | 2 + hw/i386/acpi-build.c | 98 ++++++++++++++++++++++++-- hw/i386/e820_memory_layout.h | 11 +-- hw/i386/pc.c | 35 +++++++++ hw/mem/Kconfig | 4 ++ hw/mem/meson.build | 1 + hw/mem/spm-memory.c | 133 +++++++++++++++++++++++++++++++++++ include/hw/mem/spm-memory.h | 42 +++++++++++ qapi/machine.json | 43 ++++++++++- 10 files changed, 358 insertions(+), 13 deletions(-) create mode 100644 hw/mem/spm-memory.c create mode 100644 include/hw/mem/spm-memory.h
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] and the v8 review [2].
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 series introduces 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,
mapped-state enforcement, and QMP introspection come from the
existing memory-device framework.
The series is split into four patches:
1/4 spm-memory device (boilerplate + QAPI)
2/4 acpi-build.c SRAT umbrella partition for SPM
3/4 pc machine plug-handler integration + E820 entry
4/4 MAINTAINERS coverage
Testing
-------
Verified end-to-end on q35 + KVM, with both SeaBIOS and OVMF, for:
- single spm-memory instance
- two spm-memory instances on different NUMA nodes
Guest observations: /proc/iomem shows one SOFT_RESERVED entry per
spm-memory 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 SPM ranges.
Changes since v8
----------------
- Split the single v8 patch into four bisect-safe patches.
- Drop the per-machine QLIST and the spm_addresses reservation
array; the SRAT partition iterates the device tree directly
via object_child_foreach_recursive().
- Drop spm_memory_check_node_exclusive(); the existing
memory-device framework already enforces the relevant
placement invariants.
- Slim spm_memory_realize() to a hostmem-set check; move the
is_mapped check to pc_spm_memory_pre_plug().
- Split the pc-side hookup into pre_plug and plug callbacks
dispatched from pc_machine_device_{pre_,}plug_cb, matching
the pc-dimm pattern.
- Add hw/mem/spm-memory.c and include/hw/mem/spm-memory.h to
the Memory devices entry in MAINTAINERS.
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/20260527071907.4193280-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 (Igor Mammedov):
https://lore.kernel.org/qemu-devel/20260601105057.2d764e55@imammedo/
fanhuang (4):
hw/mem: add spm-memory device for Specific Purpose Memory
i386/acpi-build: partition device_memory SRAT umbrella for SPM
hw/i386: integrate spm-memory into the pc machine plug path
MAINTAINERS: cover spm-memory under Memory devices
MAINTAINERS | 2 +
hw/i386/Kconfig | 2 +
hw/i386/acpi-build.c | 98 ++++++++++++++++++++++++--
hw/i386/e820_memory_layout.h | 11 +--
hw/i386/pc.c | 35 +++++++++
hw/mem/Kconfig | 4 ++
hw/mem/meson.build | 1 +
hw/mem/spm-memory.c | 133 +++++++++++++++++++++++++++++++++++
include/hw/mem/spm-memory.h | 42 +++++++++++
qapi/machine.json | 43 ++++++++++-
10 files changed, 358 insertions(+), 13 deletions(-)
create mode 100644 hw/mem/spm-memory.c
create mode 100644 include/hw/mem/spm-memory.h
base-commit: 5611a9268dae7b7ff99d478ed134052a9fc7e9f7
--
2.34.1
On 6/2/26 10:44, fanhuang wrote: > This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` Very nitty: but spm already includes "memory". And I think most things on the cmdline use "mem" as abbreviation. "sp-mem" ? or simply "spm" ? Thoughts? -- Cheers, David
On 6/2/2026 5:36 PM, David Hildenbrand wrote: > On 6/2/26 10:44, fanhuang wrote: >> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` > > Very nitty: but spm already includes "memory". And I think most things on the > cmdline use "mem" as abbreviation. > > "sp-mem" ? or simply "spm" ? Thoughts? > Good point — the duplication didn't quite register when I named it. I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only pattern. Will go with that in the next iteration unless you'd prefer `sp-mem`. Best regards, FangSheng Huang (Jerry)
On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote: > > > On 6/2/2026 5:36 PM, David Hildenbrand wrote: >> On 6/2/26 10:44, fanhuang wrote: >>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` >> >> Very nitty: but spm already includes "memory". And I think most things on the >> cmdline use "mem" as abbreviation. >> >> "sp-mem" ? or simply "spm" ? Thoughts? >> > Good point — the duplication didn't quite register when I named it. > I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only > pattern. Best to wait for more feedback :) -- Cheers, David
On 2/6/26 14:21, David Hildenbrand (Arm) wrote: > On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote: >> >> >> On 6/2/2026 5:36 PM, David Hildenbrand wrote: >>> On 6/2/26 10:44, fanhuang wrote: >>>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` >>> >>> Very nitty: but spm already includes "memory". And I think most things on the >>> cmdline use "mem" as abbreviation. >>> >>> "sp-mem" ? or simply "spm" ? Thoughts? >>> >> Good point — the duplication didn't quite register when I named it. >> I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only >> pattern. > > Best to wait for more feedback :) +1 for 'spm'
On Wed, 3 Jun 2026 09:45:28 +0200 Philippe Mathieu-Daudé <philmd@mailo.com> wrote: > On 2/6/26 14:21, David Hildenbrand (Arm) wrote: > > On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote: > >> > >> > >> On 6/2/2026 5:36 PM, David Hildenbrand wrote: > >>> On 6/2/26 10:44, fanhuang wrote: > >>>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` > >>> > >>> Very nitty: but spm already includes "memory". And I think most things on the > >>> cmdline use "mem" as abbreviation. > >>> > >>> "sp-mem" ? or simply "spm" ? Thoughts? > >>> > >> Good point — the duplication didn't quite register when I named it. > >> I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only > >> pattern. > > > > Best to wait for more feedback :) > > +1 for 'spm' I like spm as well, but it's a very short acronym and /me/ uselessly worrying about ambiguity and future name conflicts. perhaps: sp-mem would be better in that regards. > > >
On 6/3/2026 9:14 PM, Igor Mammedov wrote:
> On Wed, 3 Jun 2026 09:45:28 +0200
> Philippe Mathieu-Daudé <philmd@mailo.com> wrote:
>
>> On 2/6/26 14:21, David Hildenbrand (Arm) wrote:
>>> On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote:
>>>>
>>>>
>>>> On 6/2/2026 5:36 PM, David Hildenbrand wrote:
>>>>> On 6/2/26 10:44, fanhuang wrote:
>>>>>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory`
>>>>>
>>>>> Very nitty: but spm already includes "memory". And I think most things on the
>>>>> cmdline use "mem" as abbreviation.
>>>>>
>>>>> "sp-mem" ? or simply "spm" ? Thoughts?
>>>>>
>>>> Good point — the duplication didn't quite register when I named it.
>>>> I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only
>>>> pattern.
>>>
>>> Best to wait for more feedback :)
>>
>> +1 for 'spm'
>
> I like spm as well, but it's a very short acronym and /me/ uselessly
> worrying about ambiguity and future name conflicts.
>
> perhaps: sp-mem would be better in that regards.
> Confirmed — quick grep on master finds "SPM" used in four unrelated
subsystems already (AVR SPM instruction, s390x spm instruction,
m25p80 SPI flash Status Protection Mode, AHCI Staggered Power
Management). Bare `spm` would land in noisy company.
Leaning toward `sp-mem` as you suggested. Concrete before/after:
cmdline:
BEFORE: -device spm-memory,memdev=m0,node=1
AFTER: -device sp-mem,memdev=m0,node=1
file / TYPE / function (after also dropping the redundant _md_ infix
per Philippe's KISS suggestion):
BEFORE:
hw/mem/spm-memory.c TYPE_SPM_MEMORY spm_memory_md_get_addr()
AFTER:
hw/mem/sp-mem.c TYPE_SP_MEM sp_mem_get_addr()
QAPI enum value:
BEFORE: 'spm-memory'
AFTER: 'sp-mem'
Kconfig symbol:
BEFORE: CONFIG_SPM_MEMORY
AFTER: CONFIG_SP_MEM
struct + cast macro (using OBJECT_DECLARE_SIMPLE_TYPE per Philippe,
since the class struct is empty and can be dropped):
BEFORE:
OBJECT_DECLARE_TYPE(SpmMemoryDevice, SpmMemoryDeviceClass,
SPM_MEMORY)
AFTER:
OBJECT_DECLARE_SIMPLE_TYPE(SpMemDevice, SP_MEM)
David, Philippe — any preference between this and `spm`? If sp-mem
works for everyone, I'll respin accordingly.
Best regards,
FangSheng Huang (Jerry)
On 4/6/26 05:35, Huang, FangSheng (Jerry) wrote: > > > On 6/3/2026 9:14 PM, Igor Mammedov wrote: >> On Wed, 3 Jun 2026 09:45:28 +0200 >> Philippe Mathieu-Daudé <philmd@mailo.com> wrote: >> >>> On 2/6/26 14:21, David Hildenbrand (Arm) wrote: >>>> On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote: >>>>> >>>>> >>>>> On 6/2/2026 5:36 PM, David Hildenbrand wrote: >>>>>> On 6/2/26 10:44, fanhuang wrote: >>>>>>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory` >>>>>> >>>>>> Very nitty: but spm already includes "memory". And I think most >>>>>> things on the >>>>>> cmdline use "mem" as abbreviation. >>>>>> >>>>>> "sp-mem" ? or simply "spm" ? Thoughts? >>>>> Good point — the duplication didn't quite register when I named it. >>>>> I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-only >>>>> pattern. >>>> >>>> Best to wait for more feedback :) >>> >>> +1 for 'spm' >> >> I like spm as well, but it's a very short acronym and /me/ uselessly >> worrying about ambiguity and future name conflicts. >> >> perhaps: sp-mem would be better in that regards. >> Confirmed — quick grep on master finds "SPM" used in four unrelated > subsystems already (AVR SPM instruction, s390x spm instruction, > m25p80 SPI flash Status Protection Mode, AHCI Staggered Power > Management). Bare `spm` would land in noisy company. > > Leaning toward `sp-mem` as you suggested. Concrete before/after: > > cmdline: > BEFORE: -device spm-memory,memdev=m0,node=1 > AFTER: -device sp-mem,memdev=m0,node=1 > > file / TYPE / function (after also dropping the redundant _md_ infix > per Philippe's KISS suggestion): > BEFORE: > hw/mem/spm-memory.c TYPE_SPM_MEMORY spm_memory_md_get_addr() > AFTER: > hw/mem/sp-mem.c TYPE_SP_MEM sp_mem_get_addr() > > QAPI enum value: > BEFORE: 'spm-memory' > AFTER: 'sp-mem' > > Kconfig symbol: > BEFORE: CONFIG_SPM_MEMORY > AFTER: CONFIG_SP_MEM > > struct + cast macro (using OBJECT_DECLARE_SIMPLE_TYPE per Philippe, > since the class struct is empty and can be dropped): > BEFORE: > OBJECT_DECLARE_TYPE(SpmMemoryDevice, SpmMemoryDeviceClass, > SPM_MEMORY) > AFTER: > OBJECT_DECLARE_SIMPLE_TYPE(SpMemDevice, SP_MEM) All these changes LGTM! > David, Philippe — any preference between this and `spm`? If sp-mem > works for everyone, I'll respin accordingly. > > Best regards, > FangSheng Huang (Jerry) >
On 6/4/2026 2:30 PM, Philippe Mathieu-Daudé wrote:
> [Some people who received this message don't often get email from
> philmd@mailo.com. Learn why this is important at https://aka.ms/
> LearnAboutSenderIdentification ]
>
> On 4/6/26 05:35, Huang, FangSheng (Jerry) wrote:
>>
>>
>> On 6/3/2026 9:14 PM, Igor Mammedov wrote:
>>> On Wed, 3 Jun 2026 09:45:28 +0200
>>> Philippe Mathieu-Daudé <philmd@mailo.com> wrote:
>>>
>>>> On 2/6/26 14:21, David Hildenbrand (Arm) wrote:
>>>>> On 6/2/26 12:02, Huang, FangSheng (Jerry) wrote:
>>>>>>
>>>>>>
>>>>>> On 6/2/2026 5:36 PM, David Hildenbrand wrote:
>>>>>>> On 6/2/26 10:44, fanhuang wrote:
>>>>>>>> This series adds a TYPE_MEMORY_DEVICE subclass `spm-memory`
>>>>>>>
>>>>>>> Very nitty: but spm already includes "memory". And I think most
>>>>>>> things on the
>>>>>>> cmdline use "mem" as abbreviation.
>>>>>>>
>>>>>>> "sp-mem" ? or simply "spm" ? Thoughts?
>>>>>> Good point — the duplication didn't quite register when I named it.
>>>>>> I lean toward simply `spm`: matches the `dimm` / `nvdimm` acronym-
>>>>>> only
>>>>>> pattern.
>>>>>
>>>>> Best to wait for more feedback :)
>>>>
>>>> +1 for 'spm'
>>>
>>> I like spm as well, but it's a very short acronym and /me/ uselessly
>>> worrying about ambiguity and future name conflicts.
>>>
>>> perhaps: sp-mem would be better in that regards.
>> Confirmed — quick grep on master finds "SPM" used in four unrelated
>> subsystems already (AVR SPM instruction, s390x spm instruction,
>> m25p80 SPI flash Status Protection Mode, AHCI Staggered Power
>> Management). Bare `spm` would land in noisy company.
>>
>> Leaning toward `sp-mem` as you suggested. Concrete before/after:
>>
>> cmdline:
>> BEFORE: -device spm-memory,memdev=m0,node=1
>> AFTER: -device sp-mem,memdev=m0,node=1
>>
>> file / TYPE / function (after also dropping the redundant _md_ infix
>> per Philippe's KISS suggestion):
>> BEFORE:
>> hw/mem/spm-memory.c TYPE_SPM_MEMORY spm_memory_md_get_addr()
>> AFTER:
>> hw/mem/sp-mem.c TYPE_SP_MEM sp_mem_get_addr()
>>
>> QAPI enum value:
>> BEFORE: 'spm-memory'
>> AFTER: 'sp-mem'
>>
>> Kconfig symbol:
>> BEFORE: CONFIG_SPM_MEMORY
>> AFTER: CONFIG_SP_MEM
>>
>> struct + cast macro (using OBJECT_DECLARE_SIMPLE_TYPE per Philippe,
>> since the class struct is empty and can be dropped):
>> BEFORE:
>> OBJECT_DECLARE_TYPE(SpmMemoryDevice, SpmMemoryDeviceClass,
>> SPM_MEMORY)
>> AFTER:
>> OBJECT_DECLARE_SIMPLE_TYPE(SpMemDevice, SP_MEM)
>
> All these changes LGTM!
>
Thanks, Philippe. v10 also addresses the rest of your patch 1 / patch
4 review (node validation moved to pc_sp_mem_pre_plug, `.unmigratable`
comment, `DEFINE_TYPES()`, dropped `/*< private >*/` markers, R: tag
under Memory devices); diffs visible in the v10 series.
Three items deviate from your suggestion:
- DEVICE_CATEGORY_MEMORY: the enum doesn't currently exist in
include/hw/core/qdev.h, and pc-dimm / nvdimm don't set any
device category here. v10 follows the pc-dimm precedent.
- QAPI base refactor (id / memaddr / size at TYPE_MEMORY_DEVICE):
acknowledged as a pre-existing pattern across PCDIMM / NVDIMM /
VirtioMEM / SgxEPC / HvBalloon; out of scope for this series.
- MAINTAINERS squash into patch 1: Igor's v8 review asked for
MAINTAINERS as a separate patch, so v10 keeps it split as patch
4/4.
>> David, Philippe — any preference between this and `spm`? If sp-mem
>> works for everyone, I'll respin accordingly.
>>
>> Best regards,
>> FangSheng Huang (Jerry)
>>
>
>
On 5/6/26 12:40, Huang, FangSheng (Jerry) wrote: > Three items deviate from your suggestion: > > - DEVICE_CATEGORY_MEMORY: the enum doesn't currently exist in > include/hw/core/qdev.h, and pc-dimm / nvdimm don't set any > device category here. v10 follows the pc-dimm precedent. Yes, this was a question for Thomas / Igor, do we want to categorize memory devices out of misc ones? > > - QAPI base refactor (id / memaddr / size at TYPE_MEMORY_DEVICE): > acknowledged as a pre-existing pattern across PCDIMM / NVDIMM / > VirtioMEM / SgxEPC / HvBalloon; out of scope for this series. Agreed. Regards, Phil.
© 2016 - 2026 Red Hat, Inc.