Re: [RFC v2 03/14] vfio/nvidia-vgpu: introduce vGPU type uploading

[Jason Gunthorpe <jgg@nvidia.com>]

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