Re: x86 MMU: RMap Interface

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Fri, Aug 14, 2020 at 11:44:49PM -0400, contact@kevinloughlin.org wrote:
> Thanks!
> 
> Given this info, am I correct in saying that all non-MMIO guest pages are
> (1) added to the rmap upon being marked present, and (2) removed from the
> rmap upon being marked non-present?
> 
> I primarily ask because I'm observing behavior (running x86-64 guest with
> TDP/EPT enabled) wherein multiple SPTEs appear to be added to the rmap for
> the same GFN<->PFN mapping (sometimes later followed by multiple removals of
> the same GFN<->PFN mapping). My understanding was that, for a given guest,
> each GFN<->PFN mapping corresponds to exactly one rmap entry (and vice
> versa). Is this incorrect?
> 
> I observe the behavior I mentioned whether I log upon rmap updates, or upon
> mmu_spte_set() (for non-present->present) and mmu_clear_track_bits() (for
> present->non-present). Perhaps I'm missing a more obvious interface for
> logging when the PFNs backing guest pages are marked as present/non-present?

The basic premise is correct, but there are exceptions (or rather, at least
one exception that immediately comes to mind).  With TDP and no nested VMs,
a given instance of the MMU will have a 1:1 GFN:PFN mapping.  But, if the
MMU is recreated (reloaded with a different EPTP), e.g. as part of a fast
zap, then there may be mappings for the GFN:PFN in both the old MMU/EPTP
instance and the new MMU/EPTP instance, and thus multiple rmaps.

KVM currently does a fast zap (and MMU reload) when deleting memslots, which
happens multiple times during boot, so the behavior you're observing is
expected.