Re: [RFC PATCH v3 00/13] KVM: guest_memfd: Add a common framework for device memory providers

[Fred Griffoul <griffoul@gmail.com>]

"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> writes:

> This series adds the common guest_memfd support needed by device memory
> providers. It builds on the resource-provider API [1] and the existing
> folio and RAM PFN backing support.

Hi Aneesh,

We both build on Ackerley's PFN mode [1], so here is where my export
series [2] stands and what I think it would take for the two to fit.

The export lets iommufd map a guest_memfd file without pinning it:
iommufd looks up the frame behind each shared page, and guest_memfd
calls back on every change, so the IOMMU mapping follows conversions,
punch holes and provider revokes. In the next version, the lookup
only uses lookup_pfn_range(), since it runs outside the invalidate
lock, and frames carry attributes (read only for now), which Ackerley
has offered to take into his PFN mode series.

Your patches 01-05 fit well with this: the backing ops table is the
internal provider table Ackerley's base left as a TODO, and the export
hooks stay in the common paths you keep. I tried my series on top of
yours and the conflicts are mechanical.

For device memory, I see three things to align:

1) lookup_pfn_range(). 06/13 makes it optional for device providers,
   but it is the only lookup that works outside KVM's fault path. The
   export needs it, and 07/13 would benefit too, instead of calling
   get_pfn() page by page to find contiguous runs. For vfio-pci it is
   the same BAR start plus offset as get_pfn(). Could it stay
   mandatory for all PFN mode providers?

2) The memory type. The IOMMU needs to know a frame is MMIO, and a
   prefetchable BAR may want write combining, which the fixed
   noncached mapping does not allow. A frame attribute, next to read
   only, would carry it to KVM, the VMM mapping and the export.

3) vfio-pci for ordinary VMs. Today a device provider needs a realm
   (kvm_arch_gmem_device_supported()) and gets the VM and an RMM
   binding at attach. vfio-pci is probably what will make the case for
   PFN mode upstream, and that is easier if it first works as a plain
   provider for any VM, x86 included, shared pages only, with the
   realm parts (private conversion, binding, lock()/unlock()) on top.
   It would also bring back P2P: vfio-pci refuses to attach while a
   dma-buf of the device exists, and with the export iommufd can map
   the shared BAR pages through guest_memfd instead.

I'd be glad to see v4 posted, or I can wait for 7.4-rc1. I'll reply
to a couple of patches separately.

Thanks,
Fred

[1] https://lore.kernel.org/all/20261022-gmem-alternative-providers-v2-0-5dd1dc6c660a@google.com/
[2] https://lore.kernel.org/all/20261027154649.91571-1-griffoul@gmail.com/