On Wed, Dec 1, 2021 at 11:14 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Fri, Nov 19, 2021, David Matlack wrote:
> > Factor out the logic to atomically replace an SPTE with an SPTE that
> > points to a new page table. This will be used in a follow-up commit to
> > split a large page SPTE into one level lower.
> >
> > Signed-off-by: David Matlack <dmatlack@xxxxxxxxxx>
> > ---
> > arch/x86/kvm/mmu/tdp_mmu.c | 53 ++++++++++++++++++++++++++------------
> > 1 file changed, 37 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > index cc9fe33c9b36..9ee3f4f7fdf5 100644
> > --- a/arch/x86/kvm/mmu/tdp_mmu.c
> > +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> > @@ -945,6 +945,39 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu,
> > return ret;
> > }
> >
> > +/*
> > + * tdp_mmu_install_sp_atomic - Atomically replace the given spte with an
> > + * spte pointing to the provided page table.
> > + *
> > + * @kvm: kvm instance
> > + * @iter: a tdp_iter instance currently on the SPTE that should be set
> > + * @sp: The new TDP page table to install.
> > + * @account_nx: True if this page table is being installed to split a
> > + * non-executable huge page.
> > + *
> > + * Returns: True if the new page table was installed. False if spte being
> > + * replaced changed, causing the atomic compare-exchange to fail.
> > + * If this function returns false the sp will be freed before
> > + * returning.
> > + */
> > +static bool tdp_mmu_install_sp_atomic(struct kvm *kvm,
> > + struct tdp_iter *iter,
> > + struct kvm_mmu_page *sp,
> > + bool account_nx)
> > +{
> > + u64 spte;
> > +
> > + spte = make_nonleaf_spte(sp->spt, !shadow_accessed_mask);
>
> This can easily go on one line.
>
> u64 spte = make_nonleaf_spte(sp->spt, !shadow_accessed_mask);
> > +
> > + if (tdp_mmu_set_spte_atomic(kvm, iter, spte)) {
> > + tdp_mmu_link_page(kvm, sp, account_nx);
> > + return true;
> > + } else {
> > + tdp_mmu_free_sp(sp);
> > + return false;
>
> I don't think this helper should free the sp on failure, even if that's what all
> paths end up doing. When reading the calling code, it really looks like the sp
> is being leaked because the allocation and free are in different contexts. That
> the sp is consumed on success is fairly intuitive given the "install" action, but
> freeing on failure not so much.
>
> And for the eager splitting, freeing on failure is wasteful. It's extremely
> unlikely to happen often, so in practice it's unlikely to be an issue, but it's
> certainly odd since the loop is likely going to immediately allocate another sp,
> either for the current spte or for the next spte.
Good point. I'll fix this in v1.
>
> Side topic, tdp_mmu_set_spte_atomic() and friends really should return 0/-EBUSY.
> Boolean returns for errors usually end in tears sooner or later.
Agreed. I was sticking with local style here but would like to see
more of this code switch to returning ints. I'll take a look at
including that cleanup as well in v1, if not a separate pre-series.
