>> > >> > Given that, an alternative proposal that I think would work >> > for you would be to add a 'placeholder' memory node definition >> > in SRAT (so allow 0 size explicitly - might need a new SRAT >> > entry to avoid backwards compat issues). >> >> Putting all the PCI/GI/... complexity aside, I'll just raise again that >> for virtio-mem something simple like that might be helpful as well, IIUC. >> >> -numa node,nodeid=2 \ >> ... >> -device virtio-mem-pci,node=2,... \ >> >> All we need is the OS to prepare for an empty node that will get >> populated with memory later. >> >> So if that's what a "placeholder" node definition in srat could achieve >> as well, even without all of the other acpi-generic-initiator stuff, >> that would be great. > > Please no "placeholder" definitions in SRAT. One of the main thrusts of > CXL is to move away from static ACPI tables describing vendor-specific > memory topology, towards an industry standard device enumeration.
So I suppose we go with the original suggestion that aligns with the current spec description pointed by Jonathan, which is the following: A separate acpi-generic-initiator object that links only one node to the device. For each such association, a new object would be created. A previously mentioned example from Jonathan: -object acpi-generic-initiator,id=gi1,pci-dev=dev1,nodeid=10 -object acpi-generic-initiator,id=gi2,pci-dev=dev1,nodeid=11 > It is strictly OS policy about how many NUMA nodes it imagines it wants > to define within that playground. The current OS policy is one node per > "window". If a solution believes Linux should be creating more than that > I submit that's a discussion with OS policy developers, not a trip to > the BIOS team to please sprinkle in more placeholders. Linux can fully > own the policy here. The painful bit is just that it never had to > before. Whilst I agree that Linux kernel solution would be nice as a long term solution, such change could be quite involved and intrusive.
