On Mon, Jul 25, 2022, David Matlack wrote: > On Fri, Jul 22, 2022 at 07:43:16PM -0700, Junaid Shahid wrote: > > This is only used by kvm_mmu_pte_write(), which no longer actually > > creates the new SPTE and instead just clears the old SPTE. So we > > just need to check if the old SPTE was shadow-present instead of > > calling need_remote_flush(). Hence we can drop this function. It was > > incomplete anyway as it didn't take access-tracking into account. > > > > This patch should not result in any functional change. > > Even if we don't assume anything about the new SPTE, this commit flushes > TLBs in a superset of the current cases. So this change should > definitely be safe. > > And then if we assume new SPTE is 0 (which it should be), I agree this > should not result in any functional change. Nit for posterity, zapped SPTEs don't necessarily have to be '0', e.g. KVM is more than likely going to use 0x80000000_00000000 as the "zero" value for TDP MMU SPTEs so that the SUPPRESS_VE is set for "zero"-initialized SPTEs (TDX requires EPT Violation #VEs be enabled). > Reviewed-by: David Matlack <dmatlack@xxxxxxxxxx> Reviewed-by: Sean Christopherson <seanjc@xxxxxxxxxx>
