On 10/2/25 11:05 AM, Jason Gunthorpe wrote: > On Thu, Oct 02, 2025 at 10:49:21AM -0700, John Hubbard wrote: >>> Forgot to add: But I think Zhi explained that this is not necessary and can >>> be >>> controlled by the VFIO driver, i.e. the PCI driver that binds to the VF >>> itself. >> >> Yes, this is the direction that I originally (3 whole days ago, haha) had in >> mind, >> after talking with Zhi and a few others: nova-core handles PFs, and the VFIO >> driver >> handles the VFs, and use the "is virtual" logic to sort them out. > > To be clear, no matter what the VFIO driver bound to the VF should not > become entangled with any aux devices.
I was fine until you said "aux devices". :) What does that mean in this context? > > The VFIO VF driver uses pci_iov_get_pf_drvdata() to reach into the PF > to request the PF's help. Eg for live migration or things of that > nature. > > My point here is that generally we don't put profiling code in the > VFIO driver and then use pci_iov_get_pf_drvdata() to access the PF do > actually do the profiling. > > The VF cannot/should not control profiling of itself - that would be a > security problem once it is assigned to a VM. > > So the profiling resides entirely inside the PF world and should > operate without VFIO. As I've said this design is compatible with VFs > for containers and so on. So it is the strongly preferred design > pattern. > OK, that all makes sense. thanks, -- John Hubbard
