>> An admin can provide the range of nodes using numa-node-start and >> numa-node-count and link it to a device by providing its id. The following >> sample creates 8 nodes and link them to the device dev0: >> >> -numa node,nodeid=2 \ >> -numa node,nodeid=3 \ >> -numa node,nodeid=4 \ >> -numa node,nodeid=5 \ >> -numa node,nodeid=6 \ >> -numa node,nodeid=7 \ >> -numa node,nodeid=8 \ >> -numa node,nodeid=9 \ >> -device >> vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \ >> -object >> nvidia-acpi-generic-initiator,id=gi0,device=dev0,numa-node-start=2,numa-node-count=8 >> > > If you go this way, use an array of references to the numa nodes instead of a > start and number. > There is no obvious reason why they should be contiguous that I can see.
Right. > I think it is simpler the other way around though - so have the numa nodes > point at the > vfio-pci-nohotplug device. > > Why not something like > -numa node,gi=dev0 \ > -numa node,gi=dev0 \ That could be one way to do this vs the other suggestion on this thread to provide a node list through the acpi-generic-initiator object. Just that the Qemu init numa nodes before the vfio-pci device, which could affect our ability to fail in case the user provides the wrong vfio-pci id. I am fine with both approach. Will implement the node list option if there aren't any strong opinion. >> If you go this way, use an array of references to the numa nodes instead of >> a start and number. >> There is no obvious reason why they should be contiguous that I can see. > > Yup, I was looking for other places we allow a list syntax, I only > found fds=a:b:...:z, which is also used for vhostfds=. I didn't find a > property beyond the string type to hold this though. Maybe something like 'node=1-3,8-10'? > Right, a uint16List should do. Sure, thanks.