aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/include/uapi/asm
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/include/uapi/asm
parent332518706195007f9fbafa69652aa5b3cf72df24 (diff)
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/include/uapi/asm')
0 files changed, 0 insertions, 0 deletions

Privacy Policy