* [PATCH] KVM: x86: count number of zapped pages for tdp_mmu @ 2024-01-03 12:39 Liang Chen 2024-01-03 15:25 ` Sean Christopherson 0 siblings, 1 reply; 5+ messages in thread From: Liang Chen @ 2024-01-03 12:39 UTC (permalink / raw) To: pbonzini, seanjc; +Cc: kvm, liangchen.linux Count the number of zapped pages of tdp_mmu for vm stat. Signed-off-by: Liang Chen <liangchen.linux@gmail.com> --- arch/x86/kvm/mmu/tdp_mmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index 6cd4dd631a2f..7f8bc1329aac 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -325,6 +325,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared) int i; trace_kvm_mmu_prepare_zap_page(sp); + ++kvm->stat.mmu_shadow_zapped; tdp_mmu_unlink_sp(kvm, sp, shared); -- 2.40.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: x86: count number of zapped pages for tdp_mmu 2024-01-03 12:39 [PATCH] KVM: x86: count number of zapped pages for tdp_mmu Liang Chen @ 2024-01-03 15:25 ` Sean Christopherson 2024-01-04 4:14 ` Liang Chen 0 siblings, 1 reply; 5+ messages in thread From: Sean Christopherson @ 2024-01-03 15:25 UTC (permalink / raw) To: Liang Chen; +Cc: pbonzini, kvm, David Matlack +David On Wed, Jan 03, 2024, Liang Chen wrote: > Count the number of zapped pages of tdp_mmu for vm stat. Why? I don't necessarily disagree with the change, but it's also not obvious that this information is all that useful for the TDP MMU, e.g. the pf_fixed/taken stats largely capture the same information. > Signed-off-by: Liang Chen <liangchen.linux@gmail.com> > --- > arch/x86/kvm/mmu/tdp_mmu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c > index 6cd4dd631a2f..7f8bc1329aac 100644 > --- a/arch/x86/kvm/mmu/tdp_mmu.c > +++ b/arch/x86/kvm/mmu/tdp_mmu.c > @@ -325,6 +325,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared) > int i; > > trace_kvm_mmu_prepare_zap_page(sp); > + ++kvm->stat.mmu_shadow_zapped; This isn't thread safe. The TDP MMU can zap PTEs with mmu_lock held for read, i.e. this needs to be an atomic access. And tdp_mmu_unlink_sp() or even tdp_unaccount_mmu_page() seems like a better fit for the stats update. > tdp_mmu_unlink_sp(kvm, sp, shared); > > -- > 2.40.1 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: x86: count number of zapped pages for tdp_mmu 2024-01-03 15:25 ` Sean Christopherson @ 2024-01-04 4:14 ` Liang Chen 2024-01-04 18:29 ` David Matlack 0 siblings, 1 reply; 5+ messages in thread From: Liang Chen @ 2024-01-04 4:14 UTC (permalink / raw) To: Sean Christopherson; +Cc: pbonzini, kvm, David Matlack On Wed, Jan 3, 2024 at 11:25 PM Sean Christopherson <seanjc@google.com> wrote: > > +David > > On Wed, Jan 03, 2024, Liang Chen wrote: > > Count the number of zapped pages of tdp_mmu for vm stat. > > Why? I don't necessarily disagree with the change, but it's also not obvious > that this information is all that useful for the TDP MMU, e.g. the pf_fixed/taken > stats largely capture the same information. > We are attempting to make zapping specific to a particular memory slot, something like below. void kvm_tdp_zap_pages_in_memslot(struct kvm *kvm, struct kvm_memory_slot *slot) { struct kvm_mmu_page *root; bool shared = false; struct tdp_iter iter; gfn_t end = slot->base_gfn + slot->npages; gfn_t start = slot->base_gfn; write_lock(&kvm->mmu_lock); rcu_read_lock(); for_each_tdp_mmu_root_yield_safe(kvm, root, false) { for_each_tdp_pte_min_level(iter, root, root->role.level, start, end) { if (tdp_mmu_iter_cond_resched(kvm, &iter, false, false)) continue; if (!is_shadow_present_pte(iter.old_spte)) continue; tdp_mmu_set_spte(kvm, &iter, 0); } } kvm_flush_remote_tlbs(kvm); rcu_read_unlock(); write_unlock(&kvm->mmu_lock); } I noticed that it was previously done to the legacy MMU, but encountered some subtle issues with VFIO. I'm not sure if the issue is still there with TDP_MMU. So we are trying to do more tests and analyses before submitting a patch. This provides me a convenient way to observe the number of pages being zapped. > > Signed-off-by: Liang Chen <liangchen.linux@gmail.com> > > --- > > arch/x86/kvm/mmu/tdp_mmu.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c > > index 6cd4dd631a2f..7f8bc1329aac 100644 > > --- a/arch/x86/kvm/mmu/tdp_mmu.c > > +++ b/arch/x86/kvm/mmu/tdp_mmu.c > > @@ -325,6 +325,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared) > > int i; > > > > trace_kvm_mmu_prepare_zap_page(sp); > > + ++kvm->stat.mmu_shadow_zapped; > > This isn't thread safe. The TDP MMU can zap PTEs with mmu_lock held for read, > i.e. this needs to be an atomic access. And tdp_mmu_unlink_sp() or even > tdp_unaccount_mmu_page() seems like a better fit for the stats update. > Yeah, that's an issue. Perhaps it isn't worth the effort to convert mmu_shadow_zapped to atomic type or use any concurrency control means. I will just add an attribute in debugfs to keep track of the number. > > tdp_mmu_unlink_sp(kvm, sp, shared); > > > > -- > > 2.40.1 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: x86: count number of zapped pages for tdp_mmu 2024-01-04 4:14 ` Liang Chen @ 2024-01-04 18:29 ` David Matlack 2024-01-05 1:47 ` Liang Chen 0 siblings, 1 reply; 5+ messages in thread From: David Matlack @ 2024-01-04 18:29 UTC (permalink / raw) To: Liang Chen; +Cc: Sean Christopherson, pbonzini, kvm On Wed, Jan 3, 2024 at 8:14 PM Liang Chen <liangchen.linux@gmail.com> wrote: > > On Wed, Jan 3, 2024 at 11:25 PM Sean Christopherson <seanjc@google.com> wrote: > > > > +David > > > > On Wed, Jan 03, 2024, Liang Chen wrote: > > > Count the number of zapped pages of tdp_mmu for vm stat. > > > > Why? I don't necessarily disagree with the change, but it's also not obvious > > that this information is all that useful for the TDP MMU, e.g. the pf_fixed/taken > > stats largely capture the same information. > > > > We are attempting to make zapping specific to a particular memory > slot, something like below. > > void kvm_tdp_zap_pages_in_memslot(struct kvm *kvm, struct kvm_memory_slot *slot) > { > struct kvm_mmu_page *root; > bool shared = false; > struct tdp_iter iter; > > gfn_t end = slot->base_gfn + slot->npages; > gfn_t start = slot->base_gfn; > > write_lock(&kvm->mmu_lock); > rcu_read_lock(); > > for_each_tdp_mmu_root_yield_safe(kvm, root, false) { > > for_each_tdp_pte_min_level(iter, root, > root->role.level, start, end) { > if (tdp_mmu_iter_cond_resched(kvm, &iter, false, false)) > continue; > > if (!is_shadow_present_pte(iter.old_spte)) > continue; > > tdp_mmu_set_spte(kvm, &iter, 0); > } > } > > kvm_flush_remote_tlbs(kvm); > > rcu_read_unlock(); > write_unlock(&kvm->mmu_lock); > } > > I noticed that it was previously done to the legacy MMU, but > encountered some subtle issues with VFIO. I'm not sure if the issue is > still there with TDP_MMU. So we are trying to do more tests and > analyses before submitting a patch. This provides me a convenient way > to observe the number of pages being zapped. Note you could also use the existing tracepoint to observe the number of pages being zapped in a given test run. e.g. perf stat -e kvmmmu:kvm_mmu_prepare_zap_page -- <cmd> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: x86: count number of zapped pages for tdp_mmu 2024-01-04 18:29 ` David Matlack @ 2024-01-05 1:47 ` Liang Chen 0 siblings, 0 replies; 5+ messages in thread From: Liang Chen @ 2024-01-05 1:47 UTC (permalink / raw) To: David Matlack; +Cc: Sean Christopherson, pbonzini, kvm On Fri, Jan 5, 2024 at 2:29 AM David Matlack <dmatlack@google.com> wrote: > > On Wed, Jan 3, 2024 at 8:14 PM Liang Chen <liangchen.linux@gmail.com> wrote: > > > > On Wed, Jan 3, 2024 at 11:25 PM Sean Christopherson <seanjc@google.com> wrote: > > > > > > +David > > > > > > On Wed, Jan 03, 2024, Liang Chen wrote: > > > > Count the number of zapped pages of tdp_mmu for vm stat. > > > > > > Why? I don't necessarily disagree with the change, but it's also not obvious > > > that this information is all that useful for the TDP MMU, e.g. the pf_fixed/taken > > > stats largely capture the same information. > > > > > > > We are attempting to make zapping specific to a particular memory > > slot, something like below. > > > > void kvm_tdp_zap_pages_in_memslot(struct kvm *kvm, struct kvm_memory_slot *slot) > > { > > struct kvm_mmu_page *root; > > bool shared = false; > > struct tdp_iter iter; > > > > gfn_t end = slot->base_gfn + slot->npages; > > gfn_t start = slot->base_gfn; > > > > write_lock(&kvm->mmu_lock); > > rcu_read_lock(); > > > > for_each_tdp_mmu_root_yield_safe(kvm, root, false) { > > > > for_each_tdp_pte_min_level(iter, root, > > root->role.level, start, end) { > > if (tdp_mmu_iter_cond_resched(kvm, &iter, false, false)) > > continue; > > > > if (!is_shadow_present_pte(iter.old_spte)) > > continue; > > > > tdp_mmu_set_spte(kvm, &iter, 0); > > } > > } > > > > kvm_flush_remote_tlbs(kvm); > > > > rcu_read_unlock(); > > write_unlock(&kvm->mmu_lock); > > } > > > > I noticed that it was previously done to the legacy MMU, but > > encountered some subtle issues with VFIO. I'm not sure if the issue is > > still there with TDP_MMU. So we are trying to do more tests and > > analyses before submitting a patch. This provides me a convenient way > > to observe the number of pages being zapped. > > Note you could also use the existing tracepoint to observe the number > of pages being zapped in a given test run. e.g. > > perf stat -e kvmmmu:kvm_mmu_prepare_zap_page -- <cmd> Sure. Thank you! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-01-05 1:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-03 12:39 [PATCH] KVM: x86: count number of zapped pages for tdp_mmu Liang Chen 2024-01-03 15:25 ` Sean Christopherson 2024-01-04 4:14 ` Liang Chen 2024-01-04 18:29 ` David Matlack 2024-01-05 1:47 ` Liang Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox