On 04.05.17 11:37, Wanpeng Li wrote:
From: Wanpeng Li <wanpeng...@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
