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.
VFIO will somehow have to know when it changes modes
from the TSM subsystem.
I guess we could have a special channel for KVM to learn the
shared/private page by page from VFIO as some kind of "aware of CC"
importer.
Yilun is doing something like that in (there must be a newer version somewhere)
https://lore.kernel.org/all/[email protected]/
I suppose AMD needs to mangle the RMP when it changes, and KVM has to
do that.
True.
I forget what ARM does, but I seem to recall there is a call to create
a vPCI function and that is what stuffs the S2? So maybe KVM isn't
even involved? (IIRC people were talking that something else would
call the vPCI function but I haven't seen patches)
No idea what x86 does beyond it has to unmap all the MMIO otherwise
the machine crashes :P
When it is in the hypervisor area, there is no "x86" :)
The "AMD x86" does not crash if there are mappings which won't work, it
faults/fences when these are accessed.
Oh man, what a horrible mess to even contemplate. I'm going to bed.
Jason
--
Alexey
