On 10/17/2010 12:05 PM, Nadav Har'El wrote:
This patch allows the guest to enable the VMXE bit in CR4, which is a
prerequisite to running VMXON.
Whether to allow setting the VMXE bit now depends on the architecture (svm
or vmx), so its checking has moved to kvm_x86_ops->set_cr4(). This function
now returns an int: If kvm_x86_ops->set_cr4() returns 1, __kvm_set_cr4()
will also return 1, and this will cause kvm_set_cr4() will throw a #GP.
Turning on the VMXE bit is allowed only when the "nested" module option is on,
and turning it off is forbidden after a vmxon.
-static void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
+static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
{
unsigned long hw_cr4 = cr4 | (to_vmx(vcpu)->rmode.vm86_active ?
KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
+ if (cr4& X86_CR4_VMXE){
+ if (!nested)
+ return 1;
Need to check cpuid.vmx as well, otherwise we can't turn off vmx for
specific guests (only for the entire machine).
+ } else {
+ if (nested&& to_vmx(vcpu)->nested.vmxon)
+ return 1;
+ }
+
Unrelated, if nested.vmxon, shouldn't we forbid clearing certain bits of
cr0?
It occurs to me that these bits are not fixed, instead specified by an
MSR. So we can simply have the MSR allow them (if we're sure that it
would work; don't see why not).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
