On Tue, Aug 12, 2025 at 4:35 PM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > On Tue, 2025-08-12 at 15:00 -0700, Vishal Annapurve wrote: > > IMO, tieing lifetime of guest_memfd folios with that of KVM ownership > > beyond the memslot lifetime is leaking more state into guest_memfd > > than needed. e.g. This will prevent usecases where guest_memfd needs > > to be reused while handling reboot of a confidential VM [1]. > > How does it prevent this? If you really want to re-use guest memory in a fast > way then I think you would want the DPAMT to remain in place actually. It sounds > like an argument to trigger the add/remove from guestmemfd actually. With the reboot usecase, a new VM may start with it's own new HKID so I don't think we can preserve any state that's specific to the previous instance. We can only reduce the amount of state to be maintained in SEPTs/DPAMTs by using hugepages wherever possible. > > But I really question with all the work to rebuild S-EPT, and if you propose > DPAMT too, how much work is really gained by not needing to reallocate hugetlbfs > pages. Do you see how it could be surprising? I'm currently assuming there is > some missing context. I would not limit the reboot usecase to just hugepage backing scenario. guest_memfd folios (and ideally the guest_memfd files themselves) simply should be reusable outside the VM lifecycle irrespective of whether it's used to back CoCo VMs or not.
