Fred Griffoul <[email protected]> writes: > 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. >
David brought up many good points at the LPC discussion, I need to wrap my head around your model. I'll look closely at Fred and David's versions this week. These thoughts are just from reading this email, hope to get more clarification :) > The main constraint on our side is that the provider stays the authority > on which frame backs which page: Wait, is there some magic done to make struct pages represent different frames, as in PFNs? In your model, the struct page <=> PFN mapping doesn't stay constant? > it moves pages between VMs Do multiple VMs map the same physical memory at the same time, or is it a move like below? I'm thinking that if guest_memfd wraps your provider, then your provider can issue a revocation to guest_memfd (ctrl-f for kvm_gmem_provider_revoke in [1]) on the move source guest_memfd inode, then wait for an allocation request from the move target guest_memfd inode. [1] https://lpc.events/event/20/contributions/2551/attachments/2047/4693/lpc-2026-gmem-other-backends.pdf > and has to > survive a live update. guest_memfd is going to support preservation [2]. Tarun's series just preserves memory from guest_memfd's default provider (buddy allocator) now. For your provider, I imagine the preservation flow would preserve whatever metadata in guest_memfd (like the attributes in the maple tree) and then go on to notify the provider to preserve some range of PFNs (or folios). Your provider would then basically do nothing, since those PFNs already survive a live update. [2] https://lore.kernel.org/all/[email protected]/ > 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. > Will read the rest of this series and reply again :) > 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
