On Tue, Oct 17, 2023 at 10:54:19AM -0600, Alex Williamson wrote: > On Tue, 17 Oct 2023 12:28:30 -0300 > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > On Tue, Oct 17, 2023 at 09:21:16AM -0600, Alex Williamson wrote: > > > > > Do we therefore need some programatic means for the kernel driver to > > > expose the node configuration to userspace? What interfaces would > > > libvirt like to see here? Is there an opportunity that this could > > > begin to define flavors or profiles for variant devices like we have > > > types for mdev devices where the node configuration would be > > > encompassed in a device profile? > > > > I don't think we should shift this mess into the kernel.. > > > > We have a wide range of things now that the orchestration must do in > > order to prepare that are fairly device specific. I understand in K8S > > configurations the preference is using operators (aka user space > > drivers) to trigger these things. > > > > Supplying a few extra qemu command line options seems minor compared > > to all the profile and provisioning work that has to happen for other > > device types. > > This seems to be a growing problem for things like mlx5-vfio-pci where > there's non-trivial device configuration necessary to enable migration > support. It's not super clear to me how those devices are actually > expected to be used in practice with that configuration burden. Yes, it is the nature of the situation. There is lots and lots of stuff in the background here. We can nibble at some things, but I don't see a way to be completely free of a userspace driver providing the orchestration piece for every device type. Maybe someone who knows more about the k8s stuff works can explain more? > Are we simply saying here that it's implicit knowledge that the > orchestration must posses that when assigning devices exactly matching > 10de:2342 or 10de:2345 when bound to the nvgrace-gpu-vfio-pci driver > that 8 additional NUMA nodes should be added to the VM and an ACPI > generic initiator object created linking those additional nodes to the > assigned GPU? What I'm trying to say is that orchestration should try to pull in a userspace driver to provide the non-generic pieces. But, it isn't clear to me what that driver is generically. Something like this case is pretty stand alone, but mlx5 needs to interact with the networking control plane to fully provision the PCI function. Storage needs a different control plane. Few PCI devices are so stand alone they can be provisioned without complicated help. Even things like IDXD need orchestration to sort of uniquely understand how to spawn their SIOV functions. I'm not sure I see a clear vision here from libvirt side how all these parts interact in the libvirt world, or if the answer is "use openshift and the operators". Jason
