Re: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs
Jason Gunthorpe <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
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? 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.. Jason