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.
> > + return kvm_read_cr3(vcpu) & (X86_CR3_LAM_U48 |
> > X86_CR3_LAM_U57);
