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

[Alex Williamson <alex@shazbot.org>]

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.
 
> When the PF is hardware-reset via VFIO, it implicitly disrupts SR-IOV
> operations at the device level. Because this reset happens without notifying
> the core PCI driver model, the kernel drivers bound to the VFs remain loaded
> and operate under the assumption that the VF hardware is still functional.

And this is a) why we actively try to prevent VFs from being bound to
native host kernel drivers and b) part of the vf_token negotiation of
trust opt-in that must be performed by userspace drivers of the VFs.
 
> This creates a state mismatch between the kernel's view of the hardware
> and the actual device state. Subsequent attempts by the host OS or bound
> drivers to interact with the VFs will fail, leading to unexpected
> errors.

The described model is not a supported use case, there are fundamental
security issues with a userspace vfio-pci driver owning the PF with VFs
bound to in-kernel drivers.

> Disable SR-IOV on the device prior to issuing the PF reset so that the
> VFs can teardown and remove at the software level also.

The below only accounts for the close reset path, not reset in general.
Also note that the SR-IOV model in vfio-pci does have a path by which a
PF can be re-opened with existing VFs.  Whether that's actually used is
a separate question, but this fundamentally disallows that design.

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, but the behavior
here seems counter to the original design, and the use case of
in-kernel VF drivers is certainly counter to that design and guardrails
installed to prevent it.  Thanks,

Alex

> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index a113c55845e1..b36c77eb3c40 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -826,6 +826,13 @@ void vfio_pci_core_close_device(struct vfio_device *core_vdev)
>  #if IS_ENABLED(CONFIG_EEH)
>  	eeh_dev_release(vdev->pdev);
>  #endif
> +
> +	if (pci_num_vf(vdev->pdev)) {
> +		device_lock(&vdev->pdev->dev);
> +		vfio_pci_core_sriov_configure(vdev, 0);
> +		device_unlock(&vdev->pdev->dev);
> +	}
> +
>  	vfio_pci_dma_buf_cleanup(vdev);
>  
>  	vfio_pci_core_disable(vdev);