On Tue, 2025-08-26 at 17:05 -0700, Sean Christopherson wrote: > Use atomic64_dec_return() when decrementing the number of "pre-mapped" > S-EPT pages to ensure that the count can't go negative without KVM > noticing. In theory, checking for '0' and then decrementing in a separate > operation could miss a 0=>-1 transition. In practice, such a condition is > impossible because nr_premapped is protected by slots_lock, i.e. doesn't > actually need to be an atomic (that wart will be addressed shortly). > > Don't bother trying to keep the count non-negative, as the KVM_BUG_ON() > ensures the VM is dead, i.e. there's no point in trying to limp along. > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> > --- Reviewed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> This area has gone through a lot of designs. In the v19 era PAGE.ADD got performed deep inside the fault by stuffing the source page in the vCPU. Then we switched to having userspace call KVM_PRE_FAULT_MEMORY manually to pre-populare the mirror EPT, and then have TDX code look up the PFN. Then nearer the end, we switched to current code which does something like KVM_PRE_FAULT_MEMORY internally, then looks up what got faulted and does the PAGE.ADD. Then the version in this series which does it even more directly. nr_premapped got added during the KVM_PRE_FAULT_MEMORY era. I personally didn't like it, but it was needed because userspace could do unexpected things. Now it seems like its only purpose is to generate a KVM_BUG_ON() in tdx_sept_zap_private_spte(). I wonder if we could drop it all together and accept less KVM_BUG_ON() coverage. It seems weird to focus in on this specific error case. Yan, am I missing something?
