On Fri, May 02, 2025, David Hildenbrand wrote: > On 30.04.25 20:58, Ackerley Tng wrote: > > > - if (is_private) > > > + if (is_gmem) > > > return max_level; > > > > I think this renaming isn't quite accurate. > > After our discussion yesterday, does that still hold true? No. > > IIUC in __kvm_mmu_max_mapping_level(), we skip considering > > host_pfn_mapping_level() if the gfn is private because private memory > > will not be mapped to userspace, so there's no need to query userspace > > page tables in host_pfn_mapping_level(). > > I think the reason was that: for private we won't be walking the user space > pages tables. > > Once guest_memfd is also responsible for the shared part, why should this > here still be private-only, and why should we consider querying a user space > mapping that might not even exist? +1, one of the big selling points for guest_memfd beyond CoCo is that it provides guest-first memory. It is very explicitly an intended feature that the guest mappings KVM creates can be a superset of the host userspace mappings. E.g. the guest can use larger page sizes, have RW while the host has RO, etc.
