On Tue, Feb 03, 2026 at 12:07:46PM +1100, Alexey Kardashevskiy wrote: > On 29/1/26 12:16, Jason Gunthorpe wrote: > > On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote: > > > > > For a dmabuf fd, the story is the same as guest_memfd. Unless private > > > vs. shared > > > is all or nothing, and can never change, then the only entity that can > > > track that > > > info is the owner of the dmabuf. And even if the private vs. shared > > > attributes > > > are constant, tracking it external to KVM makes sense, because then the > > > provider > > > can simply hardcode %true/%false. > > > > Oh my I had not given that bit any thought. My remarks were just about > > normal non-CC systems. > > > > So MMIO starts out shared, and then converts to private when the guest > > triggers it. It is not all or nothing, there are permanent shared > > holes in the MMIO ranges too. > > > > Beyond that I don't know what people are thinking. > > > > Clearly VFIO has to revoke and disable the DMABUF once any of it > > becomes private. > > huh? Private MMIO still has to be mapped in the NPT (well, on > AMD). It is the userspace mapping which we do not want^wneed and we > do not by using dmabuf.
Well, we don't know what the DMABUF got imported into, so the non-KVM importers using the shared mapping certainly have to drop it. How exactly to make that happen is going to be interesting.. Jason
