[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgVDfG1DvUdXnd2n@google.com>
Date: Thu, 10 Feb 2022 16:55:24 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: David Matlack <dmatlack@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH 00/23] KVM: MMU: MMU role refactoring
On Thu, Feb 10, 2022, Paolo Bonzini wrote:
> On 2/10/22 02:11, Sean Christopherson wrote:
> > In a vacuum, I 100% agree that guest_role is better than cpu_role or vcpu_role,
> > but the term "guest" has already been claimed for "L2" in far too many places.
> >
> > While we're behind the bikeshed... the resulting:
> >
> > union kvm_mmu_role cpu_role;
> > union kvm_mmu_page_role mmu_role;
> >
> > is a mess. Again, I really like "mmu_role" in a vacuum, but juxtaposed with
> >
> > union kvm_mmu_role cpu_role;
> >
> > it's super confusing, e.g. I expected
> >
> > union kvm_mmu_role mmu_role;
>
> What about
>
> union kvm_mmu_page_role root_role;
> union kvm_mmu_paging_mode cpu_mode;
>
> ? I already have to remove ".base" from all accesses to mmu_role, so it's
> not much extra churn.
I'd prefer to not use "paging mode", the SDM uses that terminology to refer to
the four paging modes. My expectation given the name is that the union would
track only CR0.PG, EFER.LME, CR4.PAE, and CR4.PSE[*].
I'm out of ideas at the moment, I'll keep chewing on this while reviewing...
[*] Someone at Intel rewrote the SDM and eliminated Mode B, a.k.a. PSE 36-bit
physical paging, it's now just part of "32-bit paging". But 5-level paging is
considered it's own paging mode?!?! Lame. I guess they really want to have
exactly four paging modes...
Powered by blists - more mailing lists