Sean Christopherson <seanjc@xxxxxxxxxx> writes: > 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. Do you mean that __kvm_mmu_max_mapping_level() should, in addition to the parameter renaming from is_private to is_gmem, do something like if (is_gmem) return kvm_gmem_get_max_mapping_level(slot, gfn); and basically defer to gmem as long as gmem should be used for this gfn? There is another call to __kvm_mmu_max_mapping_level() via kvm_mmu_max_mapping_level() beginning from recover_huge_pages_range(), and IIUC that doesn't go through guest_memfd. Hence, unlike the call to __kvm_mmu_max_mapping_level() from the KVM x86 MMU fault path, guest_memfd didn't get a chance to provide its input in the form of returning max_order from kvm_gmem_get_pfn().
