linux-kernel - Re: [PATCH v5 2/7] KVM: x86/mmu: Rename NX huge pages fields/functions for consistency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2022 16:33:08 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Yan Zhao <yan.y.zhao@...el.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Mingwei Zhang <mizhang@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Ben Gardon <bgardon@...gle.com>
Subject: Re: [PATCH v5 2/7] KVM: x86/mmu: Rename NX huge pages
 fields/functions for consistency

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 :-)