[PATCH] KVM: nVMX: fix MWAIT emulation for guests

[PATCH] KVM: nVMX: fix MWAIT emulation for guests

[Wanpeng Li]

From: Wanpeng Li <wanpeng.li@hotmail.com>

The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test.

Test suite: instruction intercept
Unhandled exception 13 #GP at ip 0000000000402397
error_code=0000      rflags=00010012      cs=00000008
rax=0000000000000000 rcx=0000000004006172 rdx=0000000000402397 rbx=000000000041427d
rbp=0000000007ff8fdf rsi=0000000000000000 rdi=0000000000000004
 r8=000000000000000a  r9=00000000000003f8 r10=0000000000000000 r11=0000000000000000
 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
cr8=0000000000000000
 	STACK: @402397 401102 400459

This testcase will run mwait instruction unconditional in L2 w/o check mwait 
cpuid. The vmlauch/vmresume emulation will merge L0's requirements and L1's 
requests, kvm-unit-tests doesn't set MWAIT/MONITOR EXITING bits for vmcs12.
w/o commit 668fffa3f838 ("kvm: better MWAIT emulation for guests"), the 
MWAIT/MONITOR EXITING bits in vmcs02 will be set since it is set in vmcs01 
though not in vmcs12. However, w/ the commit the bits will not be set in vmcs02 
since the bits are both not set in vmcs01(if kvm_mwait_in_guest() returns true) 
and vmcs12.

L2 should not occupy all the cpu time on L0 when L2 is idle, this patch fix it 
by unconditional set MWAIT/MONITOR EXTING bits against vmcs02.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: "Gabriel L. Somlo" <gsomlo@gmail.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
---
 arch/x86/kvm/vmx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 29940b6..104a0c6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10098,6 +10098,13 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
 	exec_control &= ~CPU_BASED_USE_IO_BITMAPS;
 	exec_control |= CPU_BASED_UNCOND_IO_EXITING;
 
+	/*
+	 * L2 should not occupy all the cpu time on L0 when L2
+	 * is idle, exit every time.
+	 */
+	exec_control |= CPU_BASED_MWAIT_EXITING |
+			CPU_BASED_MONITOR_EXITING;
+
 	vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, exec_control);
 
 	/* EXCEPTION_BITMAP and CR0_GUEST_HOST_MASK should basically be the
-- 
2.7.4

Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

[Alexander Graf]

On 04.05.17 11:37, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@hotmail.com>
>
> The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test.
>
> Test suite: instruction intercept
> Unhandled exception 13 #GP at ip 0000000000402397
> error_code=0000      rflags=00010012      cs=00000008
> rax=0000000000000000 rcx=0000000004006172 rdx=0000000000402397 rbx=000000000041427d
> rbp=0000000007ff8fdf rsi=0000000000000000 rdi=0000000000000004
>  r8=000000000000000a  r9=00000000000003f8 r10=0000000000000000 r11=0000000000000000
>  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
> cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
> cr8=0000000000000000
>  	STACK: @402397 401102 400459
>
> This testcase will run mwait instruction unconditional in L2 w/o check mwait
> cpuid. The vmlauch/vmresume emulation will merge L0's requirements and L1's
> requests, kvm-unit-tests doesn't set MWAIT/MONITOR EXITING bits for vmcs12.
> w/o commit 668fffa3f838 ("kvm: better MWAIT emulation for guests"), the
> MWAIT/MONITOR EXITING bits in vmcs02 will be set since it is set in vmcs01
> though not in vmcs12. However, w/ the commit the bits will not be set in vmcs02
> since the bits are both not set in vmcs01(if kvm_mwait_in_guest() returns true)
> and vmcs12.
>
> L2 should not occupy all the cpu time on L0 when L2 is idle, this patch fix it
> by unconditional set MWAIT/MONITOR EXTING bits against vmcs02.

I don't understand - why not? If both L0 and L1 hypervisors allow MWAIT 
execution, why should we stop L2 from executing it?

We don't prevent L2 from running busy loops either, right?


Alex

Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

[Paolo Bonzini]

On 04/05/2017 11:37, Wanpeng Li wrote:
> 
> The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test.
> 
> Test suite: instruction intercept
> Unhandled exception 13 #GP at ip 0000000000402397
> error_code=0000      rflags=00010012      cs=00000008
> rax=0000000000000000 rcx=0000000004006172 rdx=0000000000402397 rbx=000000000041427d
> rbp=0000000007ff8fdf rsi=0000000000000000 rdi=0000000000000004
>  r8=000000000000000a  r9=00000000000003f8 r10=0000000000000000 r11=0000000000000000
>  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
> cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
> cr8=0000000000000000
>  	STACK: @402397 401102 400459

The problem is simply that the tests were not clearing eax/ecx/edx.

Update kvm-unit-tests.git, it includes the "[PATCH] vmx: correctly set
up MONITOR and MWAIT" from April 27 (message id
1493309532-14398-1-git-send-email-pbonzini@redhat.com).

Thanks,

Paolo

Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

[Wanpeng Li]

2017-05-04 18:37 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>
>
> On 04/05/2017 11:37, Wanpeng Li wrote:
>>
>> The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test.
>>
>> Test suite: instruction intercept
>> Unhandled exception 13 #GP at ip 0000000000402397
>> error_code=0000      rflags=00010012      cs=00000008
>> rax=0000000000000000 rcx=0000000004006172 rdx=0000000000402397 rbx=000000000041427d
>> rbp=0000000007ff8fdf rsi=0000000000000000 rdi=0000000000000004
>>  r8=000000000000000a  r9=00000000000003f8 r10=0000000000000000 r11=0000000000000000
>>  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
>> cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
>> cr8=0000000000000000
>>       STACK: @402397 401102 400459
>
> The problem is simply that the tests were not clearing eax/ecx/edx.

You are right, thanks for pointing out this. :)

Regards,
Wanpeng Li