Re: [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request

[Alex Mastro <amastro@fb.com>]

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/20260901093217.8539-1-skolothumtho@nvidia.com/

Alex