On Wed, Dec 28, 2022, Yan Zhao wrote:
> On Fri, Dec 23, 2022 at 12:57:38AM +0000, Sean Christopherson wrote:
> > +bool kvm_page_track_is_valid_gfn(struct kvm *kvm, gfn_t gfn)
> > +{
> > + bool ret;
> > + int idx;
> > +
> > + idx = srcu_read_lock(&kvm->srcu);
> > + ret = kvm_is_visible_gfn(kvm, gfn);
> > + srcu_read_unlock(&kvm->srcu, idx);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_page_track_is_valid_gfn);
> This implementation is only to check whether a GFN is within a visible
> kvm memslot. So, why this helper function is named kvm_page_track_xxx()?
> Don't think it's anything related to page track, and not all of its callers
> in KVMGT are for page tracking.
KVMGT is the only user of kvm_page_track_is_valid_gfn(). kvm_is_visible_gfn()
has other users, just not in x86. And long term, my goal is to allow building
KVM x86 without any exports. Killing off KVM's "internal" (for vendor modules)
exports for select Kconfigs is easy enough, add adding a dedicated page-track API
solves the KVMGT angle.
