On Mon, Nov 29, 2021, Ben Gardon wrote: > On Wed, Nov 24, 2021 at 8:19 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > > I've got a few comments below, but before that I've also got one off-topic > > question too; it'll be great if you can help answer. > > > > When I was looking into how the old code recovers the huge pages I found that > > we'll leave the full-zero pgtable page there until the next page fault, then I > > _think_ it'll be released only until the __handle_changed_spte() when we're > > dropping the old spte (handle_removed_tdp_mmu_page). > > That seems likely, though Sean's recent series that heavily refactored > zapping probably changed that. Hmm, no, that behavior shouldn't change for this path in my series. Only the leaf SPTEs are zapped, the shadow page hangs around until its replaced by a hugepage, reclaimed due to memory pressure, etc... FWIW, that's consistent with the legacy/full MMU. Zapping the SP is doable in theory, but it would require completely different iteration behavior and small amount of additional logic to check the entire gfn range covered by the SP for compability. If we were starting from scratch, I would probably advocate zapping the parent SP directly, but since the net work done is roughly equivalent, the cost of keeping the page around is negligible, and we have functional code already...
