On Sat, Oct 10, 2026, Aneesh Kumar K.V wrote: > I have been working on something similar for confidential computing use > cases. There is likely some overlap between this series and what I posted > at [1]. > > I have not reviewed this series in detail yet, but I will compare the two > approaches and identify what can be shared between the use cases. Please > let me know how you would like to proceed. > > [1] > https://lore.kernel.org/all/[email protected]/
Thanks for the pointer. I read your series, and Ackerley's resource fd RFC that it builds on. The use cases differ, but the interfaces overlap, and it would be good to agree on the common parts. All three series add a flag and an fd to KVM_CREATE_GUEST_MEMFD. I think one resource_fd is enough, with guest_memfd picking the backend from the kind of file it gets. I am happy to drop provider_fd for Ackerley's flag and field. We also find the provider from the file in three different ways; I would like us to pick one, preferably without a registry. The main constraint on our side is that the provider stays the authority on which frame backs which page: it moves pages between VMs and has to survive a live update. What would not work for us is guest_memfd becoming the primary manager of PFN memory, as Ackerley suggests. Your get_pfn() leaves VFIO as the authority for the BAR, so I think we agree there. You refuse dma-buf exports while guest_memfd is attached. That is roughly what the memory provider interface is for: one owner, several users, and one revoke that reaches all of them. A BAR exposed as a provider file could be mapped by both guest_memfd and iommufd. I plan to change the revoke anyway, because iommufd must not leave the device with a hole: it should replace mappings in place instead of unmapping and remapping. Would that fit your case? I suspect it depends on locking, for example whether you have to revoke while holding memory_lock. Shared/private state and the conversion hooks would stay in guest_memfd and the arch code, as in your series. Does that sound reasonable? Ackerley, David, any thoughts? Thanks, Fred
