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; }