Kernel KVM virtualization development
 help / color / mirror / Atom feed
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


  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