Re: [RFC PATCH v2 00/11] mm: Memory providers for guest_memfd and iommufd

[Aneesh Kumar K . V]

Fred Griffoul <griffoul@xxxxxxxxx> writes:

> From: Fred Griffoul <fgriffo@xxxxxxxxxxxx>
>

 [ ... 24 lines skipped ... ] 

>
> Why a new interface
> ===================
>
> kvm_gmem_ops gives KVM a way in. For devices, the only option today is
> a dma-buf plus a private call that iommufd looks up with symbol_get(),
> which is how vfio-pci works. Each new owner would need another such
> lookup, and iommufd would end up knowing each owner by name. With a
> common interface, a provider module only calls into mm, and nothing
> needs symbol_get().
>
> It also means the provider revokes a range once. The VMM hands the
> same file to KVM and to iommufd; on a revoke the core forwards it to
> every consumer, so KVM clears the range from stage-2, iommufd from the
> IOMMU page tables, and guest_memfd from the VMM's own mapping, all
> before the revoke returns.
>

What confused me was the introduction of memory providers as a subsystem
in their own. What we really need is the ability to map PFNs from
other subsystems into KVM stage-2 and into subsystems such as iommufd?.

Restricting the scope to the above, at least initially, would make this
much easier to reason about.

For my use case, the VFIO fd becomes the backing provider (referred to
as backend below). We can create a guest_memfd using that
resource_fd, allowing MMIO BAR ranges to be mapped into KVM stage-2.

Another feature provided by this series is the ability to map the same
range into iommufd. We probably want to restrict this to shared ranges.
It may be simpler for guest_memfd to drive this. The resulting
relationship would be:

+-----------------------+
| VFIO PCI BAR backing  |
+-----------------------+
            |
            | guest_memfd_backing_ops
            | Supplies BAR PFNs
            v
+------------------------------------------+
| guest_memfd                              |
|                                          |
| Controls shared/private state            |
| Exports shared, accessible PFNs          |
| Revokes consumer mappings when needed    |
+------------------------------------------+
            |
            | mem_provider_ops
            | IOAS_MAP_FILE(fd = guest_memfd)
            v
+-----------------------+
| IOMMUFD               |
|                       |
| Creates and refreshes |
| IOMMU DMA mappings    |
+-----------------------+
            |
            v
      Device DMA access


Another capability the memory-provider interface could provide is
kernel-initiated IOAS mapping, for example by allowing a guest_memfd fd
to be used with IOAS_MAP_FILE.

Currently, a private-to-shared conversion causes a VM exit, followed by
an IOAS_MAP for the newly shared range. Could using guest_memfd with
IOAS_MAP_FILE avoid this?

Perhaps the series could be rearranged as follows:

- Allow a guest_memfd fd to be used with IOAS_MAP_FILE.
- Add a VFIO or other backend for guest_memfd, without calling it a provider.
- Add support for guest_memfd to provide guest PFNs to other subsystems
  through its file descriptor.

Would this work?

-aneesh