aboutsummaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/mm.py
diff options
context:
space:
mode:
authorSean Christopherson <[email protected]>2022-06-07 21:35:50 +0000
committerPaolo Bonzini <[email protected]>2022-07-28 13:22:25 -0400
commitc33f6f2228fe8517e38941a508e9f905f99ecba9 (patch)
tree0cb78fa6d7c2e2b303b937be5bf2a5b096ebf3df /scripts/gdb/linux/mm.py
parentcfe12e64b0657142824819d939fcfe62f14104a1 (diff)
KVM: x86: Split kvm_is_valid_cr4() and export only the non-vendor bits
Split the common x86 parts of kvm_is_valid_cr4(), i.e. the reserved bits checks, into a separate helper, __kvm_is_valid_cr4(), and export only the inner helper to vendor code in order to prevent nested VMX from calling back into vmx_is_valid_cr4() via kvm_is_valid_cr4(). On SVM, this is a nop as SVM doesn't place any additional restrictions on CR4. On VMX, this is also currently a nop, but only because nested VMX is missing checks on reserved CR4 bits for nested VM-Enter. That bug will be fixed in a future patch, and could simply use kvm_is_valid_cr4() as-is, but nVMX has _another_ bug where VMXON emulation doesn't enforce VMX's restrictions on CR0/CR4. The cleanest and most intuitive way to fix the VMXON bug is to use nested_host_cr{0,4}_valid(). If the CR4 variant routes through kvm_is_valid_cr4(), using nested_host_cr4_valid() won't do the right thing for the VMXON case as vmx_is_valid_cr4() enforces VMX's restrictions if and only if the vCPU is post-VMXON. Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'scripts/gdb/linux/mm.py')
0 files changed, 0 insertions, 0 deletions