On Wed, May 22, 2024 at 11:09:54PM +0000, "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx> wrote: > 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. Ok. We understand the situation correctly. I think it's okay to do nothing for now with some notes somewhere as record because it doesn't affect much for usual case. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
