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

[Tian, Kevin]

> From: Alex Williamson <alex@xxxxxxxxxxx>
> Sent: Monday, August 10, 2026 11:32 PM
> 
> On Thu, 6 Aug 2026 16:47:39 -0300
> Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> 
> > 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 ..
> 
> I think we have 3 potential options for PF reset:

Is there any coordination between in-kernel PF driver and in-kernel VF
drivers regarding to reset? At a glance looks that requesting FLR on PF
via sysfs would silently affect active VFs anyway...

> 
>  a) All resets are blocked or deferred while SR-IOV is active.
> 
>  b) VF mappings are zapped/invalidated at PF reset and require
>     coordination to be reinstated.
> 
>  c) VFs are torn down on all PF resets.
> 
> Option (a) is complex and doesn't look like stable material.  A deferred
> reset on .close needs to materialize on .remove or .sriov_configure
> (and of course .open), but to allow in-kernel VF drivers we can't rely
> on vfio usage counts, or even our vf-token trust boundaries, which is
> what leads to the .sriov_configure hook since we need to take advantage
> of every opportunity to issue a deferred reset when SR-IOV is not
> active when we can only rely on the PF state.
> 
> Option (b) is potentially more simple, it implements the blocking of
> access on reset in the kernel for enforcement, but defers the
> coordination of reinstantiating mappings to userspace, which is really
> how the vf_token model is intended to work.  This is incompatible with
> in-kernel VF drivers, which I think means tainting on VF unbind from
> vfio-pci and those working outside the model would tread carefully.
> 
> Option (c) is the more heavy handed approach, it means that a PF driver
> cannot fail or exit and re-attach.  We have existing logic that handles
> a PF driver re-opening the PF device with active VFs and authenticating
> the vf_token (logic also broken by in-kernel VF drivers that bypass the
> vf_token mechanics).  There also appears to be significant locking
> challenges in this approach, ex. the inversion of getting the device
> lock for SR-IOV teardown from the ioctl, config space, and .close
> contexts.
> 
> I'm open to suggestions, PF resets with live VFs is very much a gap
> that I'd like to close in the vfio-pci SR-IOV model.  Thanks,
> 

Before closing the open on reset, does it make sense to first fit it into
the coming trust infrastructure [1]? e.g. initially set to TRUST_NONE
for any VF with a PF owned by vfio-pci, preventing any bind to
in-kernel VF drivers. Then opt-in is allowed to promote the trust of
such VFs to TRUST_ADVERSARY, allowing driver binding but also put
it in precaution with IOMMU protection. So a malicious userspace
PF driver cannot indirectly affect VFs to do dma-based attack.

somehow VFs in this scenario feel akin to Thunderbolt devices...

[1] https://lore.kernel.org/linux-coco/20260705220819.2472765-10-djbw@xxxxxxxxxx/