From: Samiullah Khawaja <skhawaja@google.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex@shazbot.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
"bhelgaas@google.com" <bhelgaas@google.com>,
Leon Romanovsky <leon@kernel.org>,
"dmatlack@google.com" <dmatlack@google.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/1] vfio/pci: Disable sriov on PF device close
Date: Mon, 10 Aug 2026 21:47:01 +0000 [thread overview]
Message-ID: <anpD2sBgwyfQAjqm@google.com> (raw)
In-Reply-To: <CO1PR11MB483582006360CC4F32F97F838CD32@CO1PR11MB4835.namprd11.prod.outlook.com>
On Wed, Aug 05, 2026 at 09:34:32AM +0000, Tian, Kevin wrote:
>> From: Samiullah Khawaja <skhawaja@google.com>
>> Sent: Wednesday, August 5, 2026 8:34 AM
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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);
>> + }
>> +
>
>Sashiko reported several locking issues with this change:
>
>https://sashiko.dev/#/patchset/20260805003355.728299-2-skhawaja%40google.com
>
>Actually it is a discouraged usage allowing kernel drivers bound to VFs
>which belongs to a PF owned by vfio userspace.
Thanks for the feedback Kevin.
I sent this as an RFC specifically to discuss the right approach for
resolving this issue before fixing the locking issues that sashiko
raised. I will get back to this once the discussion to fix this the
right way concludes in the other thread.
Thanks,
Sami
next prev parent reply other threads:[~2026-08-10 21:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 0:33 [RFC PATCH 0/1] vfio/pci: Disable sriov on PF device close Samiullah Khawaja
2026-08-05 0:33 ` [RFC PATCH 1/1] " Samiullah Khawaja
2026-08-05 1:03 ` sashiko-bot
2026-08-05 9:34 ` Tian, Kevin
2026-08-10 21:47 ` Samiullah Khawaja [this message]
2026-08-05 15:03 ` Alex Williamson
2026-08-06 19:47 ` Jason Gunthorpe
2026-08-10 15:32 ` Alex Williamson
2026-08-11 9:52 ` Tian, Kevin
2026-08-11 13:59 ` Jason Gunthorpe
2026-08-11 20:31 ` Samiullah Khawaja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anpD2sBgwyfQAjqm@google.com \
--to=skhawaja@google.com \
--cc=alex@shazbot.org \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox