On Tue, 2023-02-14 at 14:18 +0800, Chao Gao wrote: > There are two ways that make sense to me: > option 1: > > patch 1: virtualize CR4.LAM_SUP > patch 2: virtualize CR3.LAM_U48/U57 > patch 3: virtualize LAM masking on applicable data accesses And patch 4: KVM emulation: Apply LAM when emulating data access > patch 4: expose LAM CPUID bit to user sapce VMM > > > > * the current vCPU mode is accurate. > > > > */ > > > > - if (kvm_vcpu_is_illegal_gpa(vcpu, cr3)) > > > > + if (!kvm_is_valid_cr3(vcpu, cr3)) > > > > > > There are other call sites of kvm_vcpu_is_illegal_gpa() to > > > validate > > > cr3. > > > Do you need to modify them? > > > > I don't think so. Others are for gpa validation, no need to change. > > Here is for CR3. > > how about the call in kvm_is_valid_sregs()? if you don't change it, > when > user space VMM tries to set a CR3 with any LAM bits, KVM thinks the > CR3 > is illegal and returns an error. To me it means live migration > probably > is broken. Agree. Will add this check in v5. > > And the call in nested_vmx_check_host_state()? L1 VMM should be > allowed to > program a CR3 with LAM bits set to VMCS's HOST_CR3 field. Right, per spec, it should be allowed.
