Re: [RFC PATCH 1/1] vfio/pci: Disable sriov on PF device close

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Aug 05, 2026 at 09:03:23AM -0600, Alex Williamson wrote:
> On Wed,  5 Aug 2026 00:33:55 +0000
> Samiullah Khawaja <skhawaja@google.com> wrote:
> 
> > When userspace closes a VFIO device file descriptor, the vfio driver
> > performs a hardware reset on the PCIe device to ensure it is returned to
> > a clean state. However, if the closed device is an SR-IOV Physical
> > Function (PF), it may have instantiated Virtual Functions (VFs) that are
> > actively bound to host kernel drivers (or other vfio instances).
> 
> Wait, what?  We actively try to prevent VFs from a vfio-pci owned PF
> from being bound to host drivers other than vfio-pci.  You need to
> overwrite the imposed driver_override to make this happen and you're in
> a very precarious security model to have the VF owned by a trusted
> in-kernel driver while the PF is owned by userspace.

Maybe, it really depends on the device. I can easially see someone
using a device where this would be safe. mlx5 for instance is pretty
OK.

So I don't really mind someone doing this, we should block it and warn
it and so on, but like noiommu and the other vfio insecure modes, why
not give an opt in?

> It's possible there are gaps that closing the PF can interrupt the VFs
> and we need to defer a reset until the VFs are closed, 

Oh definately, when running in a SRIOV mode it is really problematic
for the PF to reset while there are any active VFs. The PF controls a
number of shared items (MMIO, ATS, etc) and when it blips everyone is
at risk of unexpected fairly catastrophic system crashing errors
related to the shared items going away.

So resetting the PF device unconditionally when vfio closes is
definately wrong in principal. I can see it maybe working for simple
systems, especially ones that don't MCE..

I don't think we can skip the PF reset on close because of dev_set
reasons and leave a rouge device for the next user, so the thing looks
somewhat troubled?

Adding the sriov disable here at least makes it defensibly safe, that
we do still clear the PF on close, and we don't take risks that the
active VFs will crash the system during the FLR blip.

Though I understand it was not the original intention, I feel we have
ended up in a strange place with the SRIOV PF feature ..

Jason