summaryrefslogtreecommitdiffstats
path: root/arch/x86/entry/syscalls/syscall_32.tbl
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2017-03-10 12:47:13 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2017-04-21 11:42:49 +0200
commitfe0e80befd4d3a62d40f24b98b17483ea00ef2dd (patch)
tree99e342939c4fdfc0ac845782625befc721b5563f /arch/x86/entry/syscalls/syscall_32.tbl
parentKVM: nVMX: fix AD condition when handling EPT violation (diff)
downloadlinux-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