Jason Gunthorpe <[email protected]> writes:
> On Sat, Jul 11, 2026 at 06:01:31PM -0700, Ackerley Tng wrote:
>
>> In the course of a CoCo guest's operation, will the guest need to
>> convert between private/shared MMIO? Will the guest need some pages
>> shared and others private? If these are required operations, guest_memfd
>> already provides the tracking and is going to have a conversion ioctl
>> very soon. Instead of further extending dmabuf to track more things, how
>> about letting guest_memfd track it?
>
> Use another FD type was sort of my fallback if we couldn't get DMABUF
> into something workable. I'm kind of surprised to see guestmemfd
> proposed as the other FD, but I don't know much about its insides.
>
For now guest_memfd only supports 4K pages, so the interfaces we're
interested in are:
+ The .fault() handler, which core mm calls to service any page
faults. For this, guest_memfd first checks if the page is shared, and
if so, proceeds to return a struct page.
+ For VFIO, guest_memfd could call vfio_pci_mmap_huge_fault() and do
vmf_insert_pfn().
+ The kvm_gmem_get_pfn() function, which kvm calls to get a pfn and a
max_order to set up stage 2 page tables. Now guest_memfd returns
folio_pfn(folio) and max_order = 0 since guest_memfd only supports
PAGE_SIZE pages now.
+ For VFIO, guest_memfd would need some way to get the PFN, so
probably something like dma_buf_get_pfn_unlocked() [1], but
probably from VFIO instead of dmabuf. Perhaps pci_resource_start()
is good enough to get a pfn.
[1]
https://lore.kernel.org/all/[email protected]/
> If VFIO can create one
At guest_memfd creation time, guest_memfd is always created for a
KVM. This is the first place where it is bound to a kvm instance. This
is one place where it helps Yilun with Confidential VMs, so KVM can be
sure that the memory was meant for a specific CoCo kvm and not any VM.
I think it might be weird to have VFIO take a kvm fd to create a
guest_memfd?
I was thinking that the userspace VMM could do something like:
int vfio_fd = open("/dev/vfio/devices/vfio0");
int gmem_fd = ioctl(KVM_CREATE_GUEST_MEMFD, { .fd = vfio_fd });
and creating from a template fd would also disable/close the vfio_fd so
that the following will fail:
addr = mmap(vfio_fd); // Maybe this should fail too?
*addr = 1; // But this should definitely fail so that
// guest_memfd gets to block private writes.
> and fill it with MMIO physical addresses then
> maybe it is OK?
>
> Jason
What interface would be used fill a guest_memfd with MMIO physical
addresses?
When a vdev is associated with a vfio file, can some other vfio file be
created that can also do MMIO to the vdev's PFNs? Would I be able to set
something to block any future associations to those PFNs? This will help
guest_memfd to prevent any other writes to private PFNs.
