Hi Leon,
On 14/09/2026 12:54, Leon Romanovsky wrote:
On Mon, Sep 14, 2026 at 08:36:47AM -0300, Jason Gunthorpe wrote:
On Sun, Sep 13, 2026 at 07:52:44PM +0300, Leon Romanovsky wrote:
On Fri, Sep 11, 2026 at 10:41:57PM +0100, Matt Evans wrote:
Expand the VFIO DMABUF revocation state to three states:
Not revoked, temporarily revoked, and permanently revoked.
The thing is that "temporarily revoked" is actually the standard
invalidate_mappings/move_notify mechanism of DMABUF, which wasn't good
for VFIO.
I think temporarily revokes here means it is revoked from a dmabuf
perspective
My guess is that this is more of a "change owner" operation than a
revoke operation.
The main issue here is that we have to guess the semantics instead of
having a properly named and documented operation.
Apologies if the cover letter for the series and patch commit message
(which cover this) are unclear about the motivations and semantics. On
the commit message, can you suggest clarifications:
"This is useful for lifecycle management, to reclaim VFIO PCI BAR
ranges previously delegated to a subordinate client process: by
revoking, the driver process can ensure that the loaned resources are
made inaccessible when the client is deemed "done". The original
DMABUF is defunct, and BAR resources can then be safely re-exported
for use by new clients."
Given what I'll explain below, do give suggestions please. There is
more context in the cover letter (the volume of which I didn't think
appropriate for the commit message).
As Christian pointed
out, the patches describe what they are doing well, but they do not
explain why they are doing it.
His comment may be warranted on the other, new, patch for DMABUF name,
but I don't think this applies here.
Just that VFIO can make it's internal dmabuf work again, there won't
be a notification to any importer or an expectation that something
like iommufd will re-establish mapping automatically.
This is principally a kernel self protection mechanism where the
userspace was expected to have removed the dmabuf before issuing a
reset/etc. If they didn't then the kernel plonks it and userspace gets
a mess to clean up.
Revoke/invalidate means that the importer should stop accessing the
buffer provided by the exporter. It does not specify what the exporter
should do afterwards.
So I still think that "temporarily revoked" is closer to
invalidate_mappings, with some additional dma-buf documentation to lose
the expectation that the buffer will become available again.
You are right in indicating in your previous email that the "temporarily
revoked" state is the old "revoked" state.
From the DMABUF importer interactions, there's _still_ only "revoked or
not revoked" state. No changes there.
From this VFIO exporter's perspective, the change is to add a "sticky"
revoked state.
The thing (as per UAPI docs, again I hope there's no guessing needed)
that the new third state gives is that a) userspace can explicitly
request it via the new ioctl/feature, and b) it is guaranteed not to be
spuriously or intentionally undone by anyone else.
E.g. reset: temporarily revoke, then un-revoke. New ioctl:
permanently revoke, such that something like a subsequent reset isn't
going to undo it and make the DMABUF usable again.
The usage scenario is:
1. Process A exports DMABUF from VFIO device. (Proc A is the
"orchestrator" here.)
2. Process A sends fd to process B.
3. Process B maps it, or hands it on, etc.
4. Process A eventually decides the buffer is finished with/lifecycle
done/wants to reuse that BAR range for something else. It permanently
revokes the DMABUF.
5. Hopefully this isn't a surprise to B (some cooperation has given it
up first) but either way, B now cannot access the BAR range anymore.
This does not _need_ cooperation, so if B becomes malicious, or crashes,
etc. A can still revoke it.
6. That BAR range is reused for something unrelated.
HTH,
Matt
