On Tue, Dec 20, 2022 at 10:07:33PM +0800, Robert Hoo wrote:
> On Mon, 2022-12-19 at 14:53 +0800, Yuan Yao wrote:
> > On Fri, Dec 09, 2022 at 12:45:53PM +0800, Robert Hoo wrote:
> > > When calc the new CR3 value, take LAM bits in.
> > >
> > > Signed-off-by: Robert Hoo <robert.hu@xxxxxxxxxxxxxxx>
> > > Reviewed-by: Jingqi Liu <jingqi.liu@xxxxxxxxx>
> > > ---
> > > arch/x86/kvm/mmu.h | 5 +++++
> > > arch/x86/kvm/vmx/vmx.c | 3 ++-
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> > > index 6bdaacb6faa0..866f2b7cb509 100644
> > > --- a/arch/x86/kvm/mmu.h
> > > +++ b/arch/x86/kvm/mmu.h
> > > @@ -142,6 +142,11 @@ static inline unsigned long
> > > kvm_get_active_pcid(struct kvm_vcpu *vcpu)
> > > return kvm_get_pcid(vcpu, kvm_read_cr3(vcpu));
> > > }
> > >
> > > +static inline u64 kvm_get_active_lam(struct kvm_vcpu *vcpu)
> > > +{
> >
> > Unlike the PCIDs, LAM bits in CR3 are not sharing with other
> > features,
> > (e.g. PCID vs non-PCIN on bit 0:11) so not check CR4[28] here should
> > be fine, otherwise follows kvm_get_pcid() looks better.
> >
> No. CR4.LAM_SUP isn't an enablement switch over CR3.LAM_U{48,57},
> they're parallel relationship, CR4.LAM_SUP controls supervisor mode
> addresses has LAM or not while CR3.LAM_U controls user mode address's
> LAM enablement.
That's right, I didn't realize this at that time, thanks. : -)
>
> > > + return kvm_read_cr3(vcpu) & (X86_CR3_LAM_U48 |
> > > X86_CR3_LAM_U57);
>
>
