On Wed, 2024-05-22 at 15:34 -0700, Isaku Yamahata wrote: > option 1. Allow per-VM kvm_mmu_max_gfn() > Pro: Conceptually easy to understand and it's straightforward to disallow > memslot creation > virtual maxphyaddr > Con: overkill for the corner case? The diff is attached. This is only when > user > space creates memlost > virtual maxphyaddr and the guest accesses GPA > > virtual maxphyaddr) It breaks the promise that gfn's don't have the share bit which is the pro for hiding the shared bit in the tdp mmu iterator. > > option 2. Keep kvm_mmu_max_gfn() and add ad hock address check. > Pro: Minimal change? > Modify kvm_handel_noslot_fault() or kvm_faultin_pfn() to reject GPA > > virtual maxphyaddr. > Con: Conceptually confusing with allowing operation on GFN > virtual > maxphyaddr. > The change might be unnatural or ad-hoc because it allow to create > memslot > with GPA > virtual maxphyaddr. I can't find any actual functional problem to just ignoring it. Just some extra work to go over ranges that aren't covered by the root. How about we leave option 1 as a separate patch and note it is not functionally required? Then we can shed it if needed. At the least it can serve as a conversation piece in the meantime.
