| Message ID | 20190104085405.40356-12-Tianyu.Lan@microsoft.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM | expand |
Hi Sean:
Thanks for your review.
On Sat, Jan 5, 2019 at 12:12 AM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Fri, Jan 04, 2019 at 04:54:05PM +0800, lantianyu1986@gmail.com wrote:
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > This patch is to flush tlb in the kvm_age_rmapp() when tlb range flush
> > is available and flush request is true.
> >
> > Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
> > ---
> > arch/x86/kvm/mmu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index a5728f51bf7d..bc402a72956a 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -1958,10 +1958,17 @@ static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
> > u64 *sptep;
> > struct rmap_iterator uninitialized_var(iter);
> > int young = 0;
> > + bool flush = (bool)data;
> >
> > for_each_rmap_spte(rmap_head, &iter, sptep)
> > young |= mmu_spte_age(sptep);
> >
> > + if (young && flush) {
> > + kvm_flush_remote_tlbs_with_address(kvm, gfn,
> > + KVM_PAGES_PER_HPAGE(level));
> > + young = 0;
> > + }
> > +
>
> young shouldn't be cleared, the tracing will be wrong and the caller
> might actually care about the return value.
Yes, this is wrong and will update.
> I'm assuming you're
> clearing young to avoid the flush in kvm_mmu_notifier_clear_flush_young(),
> but keeping that flush is silly since it will never be invoked. Just
> squash this patch with patch 10/11 so that you can remove the unnecessary
> flush in kvm_mmu_notifier_clear_flush_young() and preserve young.
>
The platform may provide tlb flush with address range as granularity. My changes
are to use range flush when it's available. kvm_mmu_notifier_clear_flush_young()
is common function for all platforms and most platforms still need the
flush in the
kvm_mmu_notifier_clear_flush_young(). I think it's better to separate
flush request and
"young" from return value of kvm_age_hva(). New flush parameter I
added in the patch 10
can be changed to a pointer and kvm_age_hva() can use it to return
flush request.
On 07/01/19 04:42, Tianyu Lan wrote: >> I'm assuming you're >> clearing young to avoid the flush in kvm_mmu_notifier_clear_flush_young(), >> but keeping that flush is silly since it will never be invoked. Just >> squash this patch with patch 10/11 so that you can remove the unnecessary >> flush in kvm_mmu_notifier_clear_flush_young() and preserve young. >> > The platform may provide tlb flush with address range as granularity. My changes > are to use range flush when it's available. kvm_mmu_notifier_clear_flush_young() > is common function for all platforms and most platforms still need the > flush in the > kvm_mmu_notifier_clear_flush_young(). I think it's better to separate > flush request and > "young" from return value of kvm_age_hva(). New flush parameter I > added in the patch 10 > can be changed to a pointer and kvm_age_hva() can use it to return > flush request. There are two possibilities: - pass a "bool *flush". If NULL, kvm_age_hva should not flush. If not NULL, kvm_age_hva should receive a true *flush, and should change it to false if kvm_age_hva takes care of the flush - pass a "bool flush". In patch 10, change all kvm_age_hva implementation to do the flush if they return 1. I think I prefer the latter, in this case the small code duplication is offset by a simpler API. Paolo
Hi Paolo:
Thanks for your review.
On Tue, Jan 8, 2019 at 12:31 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 07/01/19 04:42, Tianyu Lan wrote:
> >> I'm assuming you're
> >> clearing young to avoid the flush in kvm_mmu_notifier_clear_flush_young(),
> >> but keeping that flush is silly since it will never be invoked. Just
> >> squash this patch with patch 10/11 so that you can remove the unnecessary
> >> flush in kvm_mmu_notifier_clear_flush_young() and preserve young.
> >>
> > The platform may provide tlb flush with address range as granularity. My changes
> > are to use range flush when it's available. kvm_mmu_notifier_clear_flush_young()
> > is common function for all platforms and most platforms still need the
> > flush in the
> > kvm_mmu_notifier_clear_flush_young(). I think it's better to separate
> > flush request and
> > "young" from return value of kvm_age_hva(). New flush parameter I
> > added in the patch 10
> > can be changed to a pointer and kvm_age_hva() can use it to return
> > flush request.
>
> There are two possibilities:
>
> - pass a "bool *flush". If NULL, kvm_age_hva should not flush. If not
> NULL, kvm_age_hva should receive a true *flush, and should change it to
> false if kvm_age_hva takes care of the flush
>
> - pass a "bool flush". In patch 10, change all kvm_age_hva
> implementation to do the flush if they return 1.
>
> I think I prefer the latter, in this case the small code duplication is
> offset by a simpler API.
>
From my understanding, this means to move the flush in the
kvm_mmu_notifier_clear_flush_young()
to kvm_age_hva() and do flush in kvm_age_hva() when young is >0 and "flush"
parameter is true, right?
On 08/01/19 04:42, Tianyu Lan wrote: > From my understanding, this means to move the flush in the > kvm_mmu_notifier_clear_flush_young() > to kvm_age_hva() and do flush in kvm_age_hva() when young is >0 and "flush" > parameter is true, right? Yes. Paolo
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index a5728f51bf7d..bc402a72956a 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1958,10 +1958,17 @@ static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head, u64 *sptep; struct rmap_iterator uninitialized_var(iter); int young = 0; + bool flush = (bool)data; for_each_rmap_spte(rmap_head, &iter, sptep) young |= mmu_spte_age(sptep); + if (young && flush) { + kvm_flush_remote_tlbs_with_address(kvm, gfn, + KVM_PAGES_PER_HPAGE(level)); + young = 0; + } + trace_kvm_age_page(gfn, level, slot, young); return young; }