Ackerley Tng <[email protected]> writes: > 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?
No, our memory has no struct page: it is a carve-out hidden from the host with memmap=. I meant the mapping from guest_memfd file offset to PFN. The PFNs never change, only which file and offset they back. > Do multiple VMs map the same physical memory at the same time, or is it > a move like below? Mostly moves: a page has one owner at a time. There is also a share, where a parent keeps a range and gives a child a view of it, so two VMs can map the same frames for a while. > 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. For the guest, this series works the same way: the provider revokes the range on the source, and the target's next guest fault asks the provider for the frame. Devices are different, because a device may not support faults. So the provider also revokes the range on the target once it owns the frames, and iommufd maps them right away. In other words, a revoke means that the frames behind a range changed, whether they went away or arrived. > 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. Yes, that would work for us, as long as guest_memfd does not also have to save the offset to PFN layout: the provider keeps it across the update, and guest_memfd can ask again afterwards. Thanks, Fred
