On Mon, Jun 23, 2025, Vishal Annapurve wrote: > On Fri, Jun 20, 2025 at 9:14 AM Vishal Annapurve <vannapurve@xxxxxxxxxx> wrote: > > Adrian's suggestion makes sense and it should be functional but I am > > running into some issues which likely need to be resolved on the > > userspace side. I will keep this thread updated. > > > > Currently testing this reboot flow: > > 1) Issue KVM_TDX_TERMINATE_VM on the old VM. > > 2) Close the VM fd. > > 3) Create a new VM fd. > > 4) Link the old guest_memfd handles to the new VM fd. > > 5) Close the old guest_memfd handles. > > 6) Register memslots on the new VM using the linked guest_memfd handles. > > > > Apparently mmap takes a refcount on backing files. Heh, yep. > So basically I had to modify the reboot flow as: > 1) Issue KVM_TDX_TERMINATE_VM on the old VM. > 2) Close the VM fd. > 3) Create a new VM fd. > 4) Link the old guest_memfd handles to the new VM fd. > 5) Unmap the VMAs backed by the guest memfd > 6) Close the old guest_memfd handles. -> Results in VM destruction > 7) Setup new VMAs backed by linked guest_memfd handles. > 8) Register memslots on the new VM using the linked guest_memfd handles. > > I think the issue simply is that we have tied guest_memfd lifecycle > with VM lifecycle and that discussion is out of scope for this patch. I wouldn't say it's entirely out of scope. E.g. if there's a blocking problem _in the kernel_ that prevents utilizing KVM_TDX_TERMINATE_VM, then we definitely want to sort that out before adding support for KVM_TDX_TERMINATE_VM. But IIUC, the hiccups you've encountered essentially fall into the category of "working as intended", albeit with a lot of not-so-obvious behaviors and dependencies.
