From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Mingwei Zhang <mizhang@google.com>,
David Matlack <dmatlack@google.com>,
Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH v5 2/7] KVM: x86/mmu: Rename NX huge pages fields/functions for consistency
Date: Mon, 10 Oct 2022 16:33:08 +0000 [thread overview]
Message-ID: <Y0RJRHuUxnO7o4kO@google.com> (raw)
In-Reply-To: <Y0N96VIqxm76F3xl@yzhao56-desk.sh.intel.com>
On Mon, Oct 10, 2022, Yan Zhao wrote:
> On Fri, Sep 30, 2022 at 11:48:49PM +0000, Sean Christopherson wrote:
> <...>
> > -static void kvm_recover_nx_lpages(struct kvm *kvm)
> > +static void kvm_recover_nx_huge_pages(struct kvm *kvm)
> > {
> > unsigned long nx_lpage_splits = kvm->stat.nx_lpage_splits;
> > int rcu_idx;
> > @@ -6833,23 +6834,25 @@ static void kvm_recover_nx_lpages(struct kvm *kvm)
> > ratio = READ_ONCE(nx_huge_pages_recovery_ratio);
> > to_zap = ratio ? DIV_ROUND_UP(nx_lpage_splits, ratio) : 0;
> > for ( ; to_zap; --to_zap) {
> > - if (list_empty(&kvm->arch.lpage_disallowed_mmu_pages))
> > + if (list_empty(&kvm->arch.possible_nx_huge_pages))
> > break;
> >
> > /*
> > * We use a separate list instead of just using active_mmu_pages
> > - * because the number of lpage_disallowed pages is expected to
> > - * be relatively small compared to the total.
> > + * because the number of shadow pages that be replaced with an
> > + * NX huge page is expected to be relatively small compared to
> > + * the total number of shadow pages. And because the TDP MMU
> > + * doesn't use active_mmu_pages.
> > */
> > - sp = list_first_entry(&kvm->arch.lpage_disallowed_mmu_pages,
> > + sp = list_first_entry(&kvm->arch.possible_nx_huge_pages,
> > struct kvm_mmu_page,
> > - lpage_disallowed_link);
> > - WARN_ON_ONCE(!sp->lpage_disallowed);
> > + possible_nx_huge_page_link);
> > + WARN_ON_ONCE(!sp->nx_huge_page_disallowed);
> > if (is_tdp_mmu_page(sp)) {
> > flush |= kvm_tdp_mmu_zap_sp(kvm, sp);
> > } else {
> > kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list);
> > - WARN_ON_ONCE(sp->lpage_disallowed);
> > + WARN_ON_ONCE(sp->nx_huge_page_disallowed);
> Can this WARN_ON_ONCE(sp->nx_huge_page_disallowed) also be applied to
> tdp mmu case as it holds write lock now?
Hmm, yes. I'll tack on a patch, assuming it doesn't cause explosions. If it does
cause explosions, I'll probably just cry :-)
next prev parent reply other threads:[~2022-10-10 16:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-30 23:48 [PATCH v5 0/7] KVM: x86: Apply NX mitigation more precisely Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 1/7] KVM: x86/mmu: Tag disallowed NX huge pages even if they're not tracked Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 2/7] KVM: x86/mmu: Rename NX huge pages fields/functions for consistency Sean Christopherson
2022-10-10 2:05 ` Yan Zhao
2022-10-10 16:33 ` Sean Christopherson [this message]
2022-09-30 23:48 ` [PATCH v5 3/7] KVM: x86/mmu: Properly account NX huge page workaround for nonpaging MMUs Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 4/7] KVM: x86/mmu: Set disallowed_nx_huge_page in TDP MMU before setting SPTE Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 5/7] KVM: x86/mmu: Track the number of TDP MMU pages, but not the actual pages Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 6/7] KVM: x86/mmu: Add helper to convert SPTE value to its shadow page Sean Christopherson
2022-09-30 23:48 ` [PATCH v5 7/7] KVM: x86/mmu: explicitly check nx_hugepage in disallowed_hugepage_adjust() Sean Christopherson
2022-10-10 2:07 ` Yan Zhao
2022-10-10 16:31 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0RJRHuUxnO7o4kO@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.