On 21.06.24 01:54, Sean Christopherson wrote:
On Thu, Jun 20, 2024, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 01:30:29PM -0700, Sean Christopherson wrote:
I.e. except for blatant bugs, e.g. use-after-free, we need to be able to guarantee with 100% accuracy that there are no outstanding mappings when converting a page from shared=>private. Crossing our fingers and hoping that short-term GUP will have gone away isn't enough.
To be clear it is not crossing fingers. If the page refcount is 0 then there are no references to that memory anywhere at all. It is 100% certain.
It may take time to reach zero, but when it does it is safe.
Yeah, we're on the same page, I just didn't catch the implicit (or maybe it was explicitly stated earlier) "wait for the refcount to hit zero" part that David already clarified.
Many things rely on this property, including FSDAX.
For non-CoCo VMs, I expect we'll want to be much more permissive, but I think they'll be a complete non-issue because there is no shared vs. private to worry about. We can simply allow any and all userspace mappings for guest_memfd that is attached to a "regular" VM, because a misbehaving userspace only loses whatever hardening (or other benefits) was being provided by using guest_memfd. I.e. the kernel and system at-large isn't at risk.
It does seem to me like guest_memfd should really focus on the private aspect.
We'll likely have to enter that domain for clean huge page support and/or pKVM here either way.
Likely the future will see a mixture of things: some will use guest_memfd only for the "private" parts and anon/shmem for the "shared" parts, others will use guest_memfd for both.
If we need normal memfd enhancements of some kind to work better with KVM then that may be a better option than turning guest_memfd into memfd.
Heh, and then we'd end up turning memfd into guest_memfd. As I see it, being able to safely map TDX/SNP/pKVM private memory is a happy side effect that is possible because guest_memfd isn't subordinate to the primary MMU, but private memory isn't the core idenity of guest_memfd.
Right.
The thing that makes guest_memfd tick is that it's guest-first, i.e. allows mapping memory into the guest with more permissions/capabilities than the host. E.g. access to private memory, hugepage mappings when the host is forced to use small pages, RWX mappings when the host is limited to RO, etc.
We could do a subset of those for memfd, but I don't see the point, assuming we allow mmap() on shared guest_memfd memory. Solving mmap() for VMs that do private<=>shared conversions is the hard problem to solve. Once that's done, we'll get support for regular VMs along with the other benefits of guest_memfd for free (or very close to free).
I suspect there would be pushback from Hugh trying to teach memfd things it really shouldn't be doing.
I once shared the idea of having a guest_memfd+memfd pair (managed by KVM or whatever more genric virt infrastructure), whereby we could move folios back and forth and only the memfd pages can be mapped and consequently pinned. Of course, we could only move full folios, which implies some kind of option b) for handling larger memory chunks (gigantic pages).
But I'm not sure if that is really required and it wouldn't be just easier to let the guest_memfd be mapped but only shared pages are handed out.