Re: [PATCH] vfio/pci: Separate SR-IOV VF dev_set

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jul 03, 2025 at 02:29:04PM -0600, Alex Williamson wrote:

> > > Is there any reset which doesn't disable SRIOV? According to PCIe
> > > spec both conventional reset and FLR targeting a PF clears the
> > > VF enable bit.  
> > 
> > This is my understanding, I think there might be a little hole here in
> > the vfio SRIOV support?
> 
> I wrote a test case and we don't prevent a vfio-pci userspace driver
> from resetting the PF while also having open a VF, but I'm also not
> sure what problem that causes.
> 
> pci_restore_state() calls pci_restore_iov_state(), so VF Enable does get
> cleared by the reset (we don't actively tear down SR-IOV before reset),
> but it's restored. 

Oh interesting, I did not know that happened. Makes sense.

> Also, PF->bus != VF->bus, 

Unrelated, but I've been looking at this and I haven't tried it yet,
but it looked to me like:

	bus = virtfn_add_bus(dev->bus, pci_iov_virtfn_bus(dev, id));
 [.. inside virtfn_add_bus ]
	child = pci_find_bus(pci_domain_nr(bus), busnr);
	if (child)
		return child;

Will re-use the bus of the PF if they happen to have the same bus
numbers. I thought the virtual busses come up if the VF RID calculation:

	return dev->bus->number + ((dev->devfn + dev->sriov->offset +
				    dev->sriov->stride * vf_id) >> 8);

Exceeds the primary bus?

> so VFs don't get added to the PF dev_set.
> The PF will do a hot reset with just the PF group fd and of course FLR
> doesn't require proof of ownership of other devices.  

If the semantic of the hot reset check was to require userspace to
prove ownership of everything that gets reset it does seem like any
reset on a PF should also have ownership of the VFs. I think the UUID
is probably good enough for this though?

So that seems OK.

> Should we do more here?  What problem are we solving?  Thanks,

I think it is OK. I was originally worried the SRIOV would not come
back, but since it does that part seems fine.

Jason