On Wed, 2023-04-26 at 18:52 +0800, Binbin Wu wrote: > > On 4/26/2023 4:43 PM, Huang, Kai wrote: > > On Wed, 2023-04-26 at 11:05 +0800, Gao, Chao wrote: > > > 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. > > OK. > > > > > 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 > > Yeah performance impact is the concern. I agree we can just call out this in > > changelog and/or comments. Just want to make sure this is mentioned/discussed. > > > > My main concern is, as (any) VMEXIT saves guest's CR3 to VMCS's GUEST_CR3, KVM > > may see GUEST_CR3 containing invalid control bits (because KVM believes the > > guest doesn't support those feature bits), and if KVM code carelessly uses > > WARN() around those code, a malicious guest may be able to attack host, which > > means we need to pay more attention to code review around GUEST_CR3 in the > > future. > > How about do guest CR3 LAM bits check based on the capability of > physical processor instead of vCPU? > That is KVM doesn't prevent guest from setting CR3 LAM bits if the > processor supports LAM. > > > Doesn't seem to have any benefit as this looks like another hack (which also breaks the rule of virtualization) in order to (try to) fix a virutalization hole.
