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.
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.
(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
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)
