Re: [PATCH V2 6/8] kvm: x86/mmu: Remove FNAME(invlpg)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 10, 2023 at 9:11 AM Sean Christopherson <seanjc@xxxxxxxxxx> 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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux