On Tue, Sep 22, 2026 at 07:57:47PM -0300, Jason Gunthorpe wrote: > On Tue, Sep 22, 2026 at 03:31:07PM -0700, Alex Mastro wrote: > > > So I empathize with Matt's contention that the _existing_ behavior that the > > priv->revoked flag represents is actually "temporarily revoked": the > > importer > > can use the same dma-buf again, later, without having to re-import > > it! > > mlx5 isn't a revoking importer, it is move capable. So the above > sequence isn't a revoke, it is a move with an unmapped placement for a > while.
Ok, this is the key point I was missing, thank you. > > This is why "temporarily revoked" is a confusing phrase. > > The API is such that move and revoke importers can co-exist like this > but they experiance a different version of things.. > > We probably should not have made it have this move compatible > restoration and had things more consistent. User space can't know if > the importer is move capable or not so it has to assume revoke and it > has to go and unmap things before resetting/etc. This feels related to "vfio/pci: Handle PCI error recovery and report state to userspace" [1]. I guess in the QEMU case, the only importer of vfio dma-buf is iommufd, which makes the move-capable importer concerns moot there. Is there a plan to have QEMU re-import these dma-buf into iommufd as part of some recovery flow? (yes, we can probably move this discussion to that thread). But outside that, I cannot imagine that we'd want move-capable importers to resume using these dma-buf after events userspace didn't initiate, such as AER recovery. Userspace doesn't get the chance to intervene before a reset in that case. [1] https://lore.kernel.org/all/[email protected]/ Alex
