lkml.org 
[lkml]   [2023]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH V2 6/8] kvm: x86/mmu: Remove FNAME(invlpg)
On Fri, Feb 10, 2023 at 9:11 AM Sean Christopherson <seanjc@google.com> wrote:

>
> > + gfn_t gfn = kvm_mmu_page_get_gfn(sp, iterator.index);
> > + int ret = mmu->sync_spte(vcpu, sp, iterator.index);
> > +
> > + if (ret < 0)
> > + mmu_page_zap_pte(vcpu->kvm, sp, iterator.sptep, NULL);
> > + if (ret)
> > + kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
>
> Why open code kvm_flush_remote_tlbs_sptep()? Does it actually shave enough
> cycles to be visible?


Although I have read the code of sync_page() many times,
I don't know why I had been having the assumption that it can possibly
change the sp->gfns[] (now sp->shadowed_translation[]).

I will add the following comments before calling kvm_mmu_page_get_gfn():

Get the gfn beforehand for later flushing. Although mmu->sync_spte()
doesn't change it, but just avoid dependence.

Or I will use kvm_flush_remote_tlbs_sptep() with comments stating
that the gfn will not be changed.

>
> If open coding is really justified, can you rebase on one of the two branches?
> And then change this to kvm_flush_remote_tlbs_gfn().
>
> https://github.com/kvm-x86/linux/tree/next
> https://github.com/kvm-x86/linux/tree/mmu

The code was based on https://github.com/kvm-x86/linux/tree/mmu.

Thanks
Lai

\
 
 \ /
  Last update: 2023-03-27 00:25    [W:0.520 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site