On Sat, 2023-04-22 at 11:32 +0800, Binbin Wu wrote: > Kai, > > Thanks for your inputs. > > I rephrased the changelog as following: To me it seems there are too many details and should be trimmed down. But putting changelog aside, ... > > > LAM uses CR3.LAM_U48 (bit 62) and CR3.LAM_U57 (bit 61) to configure LAM > masking for user mode pointers. > > To support LAM in KVM, CR3 validity checks and shadow paging handling > need to be > modified accordingly. > > == CR3 validity Check == > When LAM is supported, CR3 LAM bits are allowed to be set and the check > of CR3 > needs to be modified. > Add a helper kvm_vcpu_is_legal_cr3() and use it instead of > kvm_vcpu_is_legal_gpa() > to do the new CR3 checks in all existing CR3 checks as following: > When userspace sets sregs, CR3 is checked in kvm_is_valid_sregs(). > Non-nested case > - When EPT on, CR3 is fully under control of guest. > - When EPT off, CR3 is intercepted and CR3 is checked in kvm_set_cr3() > during > CR3 VMExit handling. ... when EPT is on, as you mentioned guest can update CR3 w/o causing VMEXIT to KVM. Is there any global enabling bit in any of CR to turn on/off LAM globally? It seems there isn't because AFAICT the bits in CR4 are used to control super mode linear address but not LAM in global? So if it is true, then it appears hardware depends on CPUID purely to decide whether to perform LAM or not. Which means, IIRC, when EPT is on, if we don't expose LAM to the guest on the hardware that supports LAM, I think guest can still enable LAM in CR3 w/o causing any trouble (because the hardware actually supports this feature)? If it's true, it seems we should trap CR3 (at least loading) when hardware supports LAM but it's not exposed to the guest, so that KVM can correctly reject any LAM control bits when guest illegally does so?
