On Wed, Oct 22, 2025, Yan Zhao wrote:
> On Thu, Oct 16, 2025 at 05:32:28PM -0700, Sean Christopherson wrote:
> > Opportunistically pass the spte instead of the pfn, as the API is clearly
> > about removing an spte.
> >From my perspective, "remove_external_spte" means removing an external SPTE
> >(not
> a mirror SPTE). So passing in pfn_for_gfn seems reasonable as well.
>
> Additionally, passing in the pfn eliminates potential concerns about incorrect
> spte content.
No, it just makes bugs harder to debug. E.g. it doesn't magically guarantee the
@pfn matches the pfn that was mapped into the S-EPT.
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index 48598d017d6f..7e92aebd07e8 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1855,8 +1855,8 @@ struct kvm_x86_ops {
> > void *external_spt);
> >
> > /* Update external page table from spte getting removed, and flush TLB.
> > */
> > - int (*remove_external_spte)(struct kvm *kvm, gfn_t gfn, enum pg_level
> > level,
> > - kvm_pfn_t pfn_for_gfn);
> > + void (*remove_external_spte)(struct kvm *kvm, gfn_t gfn, enum pg_level
> > level,
> > + u64 spte);
Thinking more about what "spte" actually tracks, I think I'll rename it to
"mirror_spte".
> Also update set_external_spte?
Ooh, yeah, good call. And we can use the mirror_spte information to assert that
KVM expects full RWX permissions, e.g. that we aren't creation a security hole
by
letting the guest write memory that KVM thinks is read-only (extreme paranoia,
more for documentation purposes).
