On Wed, Apr 26, 2023 at 06:48:21AM +0800, Huang, Kai wrote: >... 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? Right. > >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)? Yes. But I think it is a non-issue ... > >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? > Other features which need no explicit enablement (like AVX and other new instructions) have the same problem. The impact is some guests can use features which they are not supposed to use. Then they might be broken after migration or kvm's instruction emulation. But they put themselves at stake, KVM shouldn't be blamed. The downside of intercepting CR3 is the performance impact on existing VMs (all with old CPU models and thus all have no LAM). If they are migrated to LAM-capable parts in the future, they will suffer performance drop even though they are good tenents (i.e., won't try to use LAM). IMO, the value of preventing some guests from setting LAM_U48/U57 in CR3 when EPT=on cannot outweigh the performance impact. So, I vote to document in changelog or comments that: A guest can enable LAM for userspace pointers when EPT=on even if LAM isn't exposed to it. KVM doens't prevent this out of performance consideration
