On Thu, Sep 04, 2025 at 02:45:34PM +0200, Danilo Krummrich wrote: > On Thu Sep 4, 2025 at 2:15 PM CEST, Jason Gunthorpe wrote: > > On Thu, Sep 04, 2025 at 11:41:03AM +0200, Danilo Krummrich wrote: > > > >> > Another note: I don't see any use of the auxiliary bus in vGPU, any clients > >> > should attach via the auxiliary bus API, it provides proper matching where > >> > there's more than on compatible GPU in the system. nova-core already registers > >> > an auxiliary device for each bound PCI device. > > > > The driver here attaches to the SRIOV VF pci_device, it should obtain the > > nova-core handle of the PF device through pci_iov_get_pf_drvdata(). > > > > This is the expected design of VFIO drivers because the driver core > > does not support a single driver binding to two devices (aux and VF) > > today. > > Yeah, that's for the VF PCI devices, but I thought vGPU will also have some kind > of "control instance" for each physical device through which it can control the > creation of VFs? I recall there is something on the PF that is independent of the VFs, but it is hard to stick that in an aux device, it will make the the lifetime model very difficult since aux devices can become unbound at any time while the vf is using it. It is alot easier to be part of the PF driver somehow.. Then userspace activities like provisioning VFs I hope we will see that done through fwctl as the networking drivers are doing. I see this series is using request_firmware() to get VF profiles and some sysfs, which seems inconsisent with any other VF provisioning scheme in the kernel. Jason
