On Tue, Jul 08, 2025, Rick P Edgecombe wrote: > On Tue, 2025-07-08 at 11:03 -0700, Sean Christopherson wrote: > > > I think there is interest in de-coupling it? > > > > No? > > I'm talking about the intra-host migration/reboot optimization stuff. And not > doing a good job, sorry. > > > Even if we get to a point where multiple distinct VMs can bind to a single > > guest_memfd, e.g. for inter-VM shared memory, there will still need to be a > > sole > > owner of the memory. AFAICT, fully decoupling guest_memfd from a VM would add > > non-trivial complexity for zero practical benefit. > > I'm talking about moving a gmem fd between different VMs or something using > KVM_LINK_GUEST_MEMFD [0]. Not advocating to try to support it. But trying to > feel out where the concepts are headed. It kind of allows gmem fds (or just > their source memory?) to live beyond a VM lifecycle. I think the answer is that we want to let guest_memfd live beyond the "struct kvm" instance, but not beyond the Virtual Machine. From a past discussion on this topic[*]. : No go. Because again, the inode (physical memory) is coupled to the virtual machine : as a thing, not to a "struct kvm". Or more concretely, the inode is coupled to an : ASID or an HKID, and there can be multiple "struct kvm" objects associated with a : single ASID. And at some point in the future, I suspect we'll have multiple KVM : objects per HKID too. : : The current SEV use case is for the migration helper, where two KVM objects share : a single ASID (the "real" VM and the helper). I suspect TDX will end up with : similar behavior where helper "VMs" can use the HKID of the "real" VM. For KVM, : that means multiple struct kvm objects being associated with a single HKID. : : To prevent use-after-free, KVM "just" needs to ensure the helper instances can't : outlive the real instance, i.e. can't use the HKID/ASID after the owning virtual : machine has been destroyed. : : To put it differently, "struct kvm" is a KVM software construct that _usually_, : but not always, is associated 1:1 with a virtual machine. : : And FWIW, stashing the pointer without holding a reference would not be a complete : solution, because it couldn't guard against KVM reusing a pointer. E.g. if a : struct kvm was unbound and then freed, KVM could reuse the same memory for a new : struct kvm, with a different ASID/HKID, and get a false negative on the rebinding : check. Exactly what that will look like in code is TBD, but the concept/logic holds up. [*] https://lore.kernel.org/all/ZOO782YGRY0YMuPu@xxxxxxxxxx > [0] https://lore.kernel.org/all/cover.1747368092.git.afranji@xxxxxxxxxx/ > https://lore.kernel.org/kvm/cover.1749672978.git.afranji@xxxxxxxxxx/
