summaryrefslogtreecommitdiffstats
path: root/drivers/xen/xen-acpi-pad.c
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2022-06-07 23:35:50 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2022-07-28 19:22:25 +0200
commitc33f6f2228fe8517e38941a508e9f905f99ecba9 (patch)
tree0cb78fa6d7c2e2b303b937be5bf2a5b096ebf3df /drivers/xen/xen-acpi-pad.c
parentKVM: selftests: Add an option to run vCPUs while disabling dirty logging (diff)
downloadlinux-c33f6f2228fe8517e38941a508e9f905f99ecba9.tar.xz
linux-c33f6f2228fe8517e38941a508e9f905f99ecba9.zip
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: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220607213604.3346000-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'drivers/xen/xen-acpi-pad.c')
0 files changed, 0 insertions, 0 deletions