[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yiedukl6MC8OAAog@google.com>
Date: Tue, 8 Mar 2022 18:17:30 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
dmatlack@...gle.com
Subject: Re: [PATCH v2 11/25] KVM: x86/mmu: remove
kvm_calc_shadow_root_page_role_common
On Tue, Mar 08, 2022, Paolo Bonzini wrote:
> On 3/8/22 18:48, Sean Christopherson wrote:
> > On Mon, Feb 21, 2022, Paolo Bonzini wrote:
> > > kvm_calc_shadow_root_page_role_common is the same as
> > > kvm_calc_cpu_mode except for the level, which is overwritten
> > > afterwards in kvm_calc_shadow_mmu_root_page_role
> > > and kvm_calc_shadow_npt_root_page_role.
> > >
> > > role.base.direct is already set correctly for the CPU mode,
> > > and CR0.PG=1 is required for VMRUN so it will also be
> > > correct for nested NPT.
> >
> > Bzzzt, this is wrong, the nested NPT MMU is indirect but will be computed as direct.
>
> CR0.PG=1 means it's *not* direct:
>
> > + role.base.direct = !____is_cr0_pg(regs);
Ha! I was just cleverly making the case for checking ____is_cr0_pg() instead of
"direct" for computing the dependent flags, I swear...
On a serious note, can we add a WARN_ON_ONCE(role.base.direct)? Not so much that
the WARN will be helpful, but to document the subtle dependency? If the relevant
code goes away in the end, ignore this requrest.
Powered by blists - more mailing lists