diff options
author | David Hildenbrand <david@redhat.com> | 2017-03-10 12:47:13 +0100 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2017-04-21 11:42:49 +0200 |
commit | fe0e80befd4d3a62d40f24b98b17483ea00ef2dd (patch) | |
tree | 99e342939c4fdfc0ac845782625befc721b5563f /arch/x86/entry/syscalls/syscall_32.tbl | |
parent | KVM: nVMX: fix AD condition when handling EPT violation (diff) | |
download | linux-fe0e80befd4d3a62d40f24b98b17483ea00ef2dd.tar.xz linux-fe0e80befd4d3a62d40f24b98b17483ea00ef2dd.zip |
KVM: VMX: drop vmm_exclusive module parameter
vmm_exclusive=0 leads to KVM setting X86_CR4_VMXE always and calling
VMXON only when the vcpu is loaded. X86_CR4_VMXE is used as an
indication in cpu_emergency_vmxoff() (called on kdump) if VMXOFF has to be
called. This is obviously not the case if both are used independtly.
Calling VMXOFF without a previous VMXON will result in an exception.
In addition, X86_CR4_VMXE is used as a mean to test if VMX is already in
use by another VMM in hardware_enable(). So there can't really be
co-existance. If the other VMM is prepared for co-existance and does a
similar check, only one VMM can exist. If the other VMM is not prepared
and blindly sets/clears X86_CR4_VMXE, we will get inconsistencies with
X86_CR4_VMXE.
As we also had bug reports related to clearing of vmcs with vmm_exclusive=0
this seems to be pretty much untested. So let's better drop it.
While at it, directly move setting/clearing X86_CR4_VMXE into
kvm_cpu_vmxon/off.
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/x86/entry/syscalls/syscall_32.tbl')
0 files changed, 0 insertions, 0 deletions