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