KVM RFC extends guest_memfd with VFIO and alternate memory providers

Ackerley Tng of Google has posted a third RFC toward letting KVM’s guest_memfd draw memory from providers other than its built-in allocator, including tmpfs, a sample contiguous-page backend, and VFIO PCI devices.

guest_memfd is the KVM interface that gives confidential VMs a file-descriptor handle for memory that can flip between shared and private. Until now it has been tied to a single internal source of pages. The RFC aims to open that path so other subsystems can supply folios or raw PFNs while KVM still owns the shared-versus-private lifecycle that confidential computing depends on.

The series is framed as a roadmap rather than a merge candidate. Tng plans to split it into smaller upstreamable chunks: alternate folio providers illustrated with tmpfs, a sample provider, KVM support for PFN-mode backends, wiring the sample into that mode, and finally making VFIO itself a guest_memfd PFN-mode provider.

For devices, the design separates a control plane from a data plane. A new VFIO bind flag marks a descriptor as control-only: configuration and non-mappable operations stay on the VFIO side, while mappable BARs, mmap, and shared/private conversions move onto the guest_memfd descriptor. mmap of BARs, ioeventfd registration, and dmabuf export are blocked on the control-only path so confidential I/O stacks do not have to manage them twice. guest_memfd is also required to hold exclusive access to the underlying resource, following a direction attributed to Sean Christopherson.

Selftests exercise an Intel 82576 under both direct VFIO access and guest_memfd mediation, covering BAR read/write and mmap, reset, low-power BAR revocation, guest stage-2 mapping, and attribute conversions. Private conversion is allowed on ordinary MMIO BARs but rejected on regions that hold MSI-X tables, which host drivers must still program.

If the approach lands, confidential guests could treat passthrough device memory with the same shared/private controls already used for ordinary RAM, a prerequisite for tighter confidential I/O without giving the host unmediated access to guest-private BARs.