Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2026-02-03 18:13:24
Also in:
cgroups, kvm, linux-doc, linux-fsdevel, linux-kselftest, linux-mm, lkml
On Tue, Feb 03, 2026 at 12:07:46PM +1100, Alexey Kardashevskiy wrote:
On 29/1/26 12:16, Jason Gunthorpe wrote:quoted
On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote:quoted
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