On Fri, 2026-09-25 at 17:50 -0700, Ackerley Tng via B4 Relay wrote: > > === What if my provider doesn't deal with pages? > > Frank and David Woodhouse [2] have use cases for providers that use > PFNs, and this is definitely something a generic interface must > support. > > Here are some options I can think of: > > 1. Don't define .alloc_folio(), instead define .alloc_pfn() > 2. Refactor .alloc_folio() to .alloc_pfn() > > Either way, I think guest_memfd should still be the primary manager of > the memory.
Thanks for working on this. I'm not sure what you mean by 'primary manager' here but my use case is for the provider to be the ultimate arbiter of who owns which PFN, and revocation of the same. Think of it like a filesystem backed by external memory. Each guest's memory is a file, and a guest can *donate* specific pages of its memory to other guests (which in the context of the *interface* only means that we need revocation). Should I be trying to rework parts of my series to live on top of this? Things I have working but which I don't see here include: • PFN support (which you mentioned). • IOMMUFD support via dma-buf. • Revocation (which I've tested correctly breaks down large pages in both EPT/NPT and IOMMU). • AsyncPF support for pages requested by KVM.
smime.p7s
Description: S/MIME cryptographic signature
