On Thu, 21 May 2026 18:41:35 +0800
"Huang, FangSheng (Jerry)" <[email protected]> wrote:
> Hi Igor,
>
> Thanks for the candor in this round, and for laying out the
> architectural reasoning rather than just the position. The framing is
> clear: an RFC with a rough prototype demonstrating the device-based
> approach, and the interface decision after that exploration
> converges. That's a reasonable bar and I'm glad to converge on it.
>
> Two of your clarifications particularly helped me converge:
>
> - SPM belongs to the memory-device family by design, not as an
> extension of built-in RAM.
> - The v4 -object/backend-property rejection is scoped to that form,
> not to any device-based shape -- so `-device spm-memory` doesn't
> carry the v4 risk forward.
Not sure what you a taking about, with device approach you will use
backend property ('memdev' if i recall correctly) to connect backend
(whatever it might be) to front-end (device model).
>
> One thing I should mention while we're aligning: in parallel with
> this thread, I've actually been prototyping the spm-memory device
> direction you outlined. I held off bringing it into the v7
> discussion because I didn't want to muddy the interface debate with
> implementation specifics before the direction was settled. Now that
> you've made the path explicit, I can share what I've found and move
> the discussion to the v8 / RFC thread properly.
>
> A short prototype status and a couple of architectural findings
> below. Some you've likely thought through already; raising them so
> the v8 thread has a starting point.
>
> (1) Prototype status
>
> A working `spm-memory` prototype inheriting from TYPE_MEMORY_DEVICE
> -- end-to-end verified on both SeaBIOS and OVMF across single,
> multi-instance, and mixed-with-pc-dimm scenarios.
>
> (2) Umbrella overlap finding + proposed mitigation for your read
>
> The umbrella SRAT entry at acpi-build.c:1510-1515 (PXM =
> nb_numa_nodes - 1, covering the full device_memory length per
> pc.c:615) overlaps every per-device entry by construction. Any
> driver that first-match-by-PXM via SRAT walk lands on the
> umbrella's range rather than the device's actual range.
>
> Mitigation in the prototype: in acpi-build.c, skip the umbrella
> when every plugged memory device is TYPE_SPM_MEMORY. Empty
> device_memory and mixed configs (SPM + pc-dimm / nvdimm /
> virtio-mem) keep the umbrella, preserving Windows hotplug /
> Linux <4G SWIOTLB. Verified in both directions. Honest scoping:
> mixed mode still has the overlap, so this is a partial
> mitigation.
I'd suggest to:
1: make smp-memory not hotpluggable
2: when SRAT is built, partition 'umbrella region' region on chunks
(current hotplug kind and spm kind). that will fragment the region
and limit what can be (hot)plugged later on (especially if spm in the
middle),
but that will be the edge case, and user can reconfigure QEMU to
put spm 1st and DIMMs on top.
If we do it like this, then mixed scenarios should work just fine.
>
> (3) Process
>
> I'll prepare a v8 PATCH series along the lines you sketched:
>
> - spm-memory device class (TYPE_MEMORY_DEVICE base for first cut)
> - drop the `reserved` enum value
> - commit message with the bigger-picture rationale
ps:
it would be nice to put references to previous versions in cover letter,
so it wouldn't be pain to find them (especially when threads are renamed)
>
> I'll post the RFC on qemu-devel under a fresh subject so the
> device-based discussion can start clean.
>
> Setting the v7 memmap-type discussion aside accordingly. Thanks
> again for the patience.
>
> Best regards,
> FangSheng Huang (Jerry)
>
