From: Samiullah Khawaja <skhawaja@google.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
Alex Williamson <alex.williamson@nvidia.com>,
"Tian, Kevin" <kevin.tian@intel.com>, kvm <kvm@vger.kernel.org>,
Alex Williamson <alex@shazbot.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>,
iommu@lists.linux.dev
Subject: Re: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs
Date: Fri, 21 Aug 2026 02:20:55 +0000 [thread overview]
Message-ID: <aoeffe1v--CgRK0a@google.com> (raw)
In-Reply-To: <20260820233722.GA1110819@ziepe.ca>
On Thu, Aug 20, 2026 at 08:37:22PM -0300, Jason Gunthorpe wrote:
>On Thu, Aug 20, 2026 at 10:38:07PM +0000, Samiullah Khawaja wrote:
>
>> > The blocking domain operation looks like it might be simplest to
>> > implement in the IOMMU core. We can set a flag for a default blocking
>> > domain on the IOMMU group when we take_dma_ownership of the group. Then
>> > release_dma_ownership picks the blocking rather than default domain.
>> >
>> > This is then unwound in use_default_domain, called via dma_configure,
>> > attaching the device to the default domain in probe of the next driver.
>> > Therefore until probe by another driver, a device used by vfio would
>> > remain in a blocking domain even while unused and unbound.
>>
>> The devices are expected to be attached to the default_domain even when
>> these are unbound and the use_default_domain assumes that, and it only
>> checks the ownership and doesn't switch the domain to default_domain. I
>> guess we should add a WARN in use_default_domain() if that is not true.
>> I will probably send out a patch for that separately.
>>
>> I think we can move the device back to default_domain after reset after
>> unbind, maybe it can be done in pci_dma_cleanup() based on
>> driver_managed_dma?
>
>This blocking domain stuff sounds very similar to what Nicolin
>implemented for the per-function ATS issue?
I see you are talking about this invalidation stuff:
https://lore.kernel.org/all/348c50ab6e95b5ec6d48ee3fa05d529a784a34c3.1765834788.git.nicolinc@nvidia.com/
But this was the case where the device is going to be reset and to
prevent ATS issues, we attach it to blocking domain before doing the
reset. But of course, with the PF reset here, it induces the same kind
of ATS issues on the VFs.
>
>Broadly we must setup a blocking domain in the iommu if ATS is
>available across reset or you get these ATS related issues.
>
>I think at the time he looked at doing SRIOV as well but it was
>tricky..
Hmm... doing that for SRIOV also, by allowing PF reset but attaching the
VFs to blocking domains before the PF is reset, will only resolve the
ATS issues. But the software state is still out of sync with hardware
state.
>
>Jason
Sami
next prev parent reply other threads:[~2026-08-21 2:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 4:53 [RFC PATCH 0/5] PCI/vfio-pci: Guard resets against active SR-IOV VFs Alex Williamson
2026-08-12 4:53 ` [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs Alex Williamson
2026-08-12 5:01 ` sashiko-bot
2026-08-13 23:22 ` Samiullah Khawaja
2026-08-14 14:37 ` Alex Williamson
2026-08-14 15:54 ` Samiullah Khawaja
2026-08-17 12:18 ` Jason Gunthorpe
2026-08-18 7:07 ` Tian, Kevin
2026-08-18 14:03 ` Jason Gunthorpe
2026-08-18 20:39 ` Alex Williamson
2026-08-20 22:38 ` Samiullah Khawaja
2026-08-20 23:37 ` Jason Gunthorpe
2026-08-21 2:20 ` Samiullah Khawaja [this message]
2026-08-12 4:53 ` [RFC PATCH 2/5] PCI: Add pci_reset_bus_cond() for a caller-gated slot or bus reset Alex Williamson
2026-08-12 5:00 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 3/5] vfio/pci: Refuse to reset an SR-IOV PF with enabled VFs Alex Williamson
2026-08-12 5:02 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 4/5] PCI: Export pci_reset_supported() Alex Williamson
2026-08-12 4:59 ` sashiko-bot
2026-08-12 4:53 ` [RFC PATCH 5/5] vfio/pci: Use pci_reset_supported() in place of reset_works Alex Williamson
2026-08-12 4:59 ` sashiko-bot
2026-08-12 21:45 ` [RFC PATCH 0/5] PCI/vfio-pci: Guard resets against active SR-IOV VFs Bjorn Helgaas
2026-08-12 22:53 ` Alex Williamson
2026-08-17 20:23 ` Tony Nguyen
2026-08-13 22:30 ` 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=aoeffe1v--CgRK0a@google.com \
--to=skhawaja@google.com \
--cc=alex.williamson@nvidia.com \
--cc=alex@shazbot.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
/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