* [ help ] vcpu handle MWAIT different
@ 2017-06-09 3:47 Longpeng (Mike)
2017-06-09 3:52 ` Longpeng (Mike)
0 siblings, 1 reply; 4+ messages in thread
From: Longpeng (Mike) @ 2017-06-09 3:47 UTC (permalink / raw)
To: Radim Krčmář, Paolo Bonzini, Wanpeng Li
Cc: kvm, Michael S. Tsirkin, Gonglei
Hi guys,
I wrote a testcase which repeat execute MWAIT insn in kvm-unit-test and I tested
it on different hardware, but got different results.
1) cpu: E5620 (hardware don't support MONITOR/MWAIT)
This works well because I saw the following info in trace:
CPU 0/KVM-7301 [015] .... 1534719.099573: kvm_exit: reason
MWAIT_INSTRUCTION rip 0x400387 info 0 0
CPU 0/KVM-7301 [015] d... 1534719.099573: kvm_entry: vcpu 0
CPU 0/KVM-7301 [015] .... 1534719.099574: kvm_exit: reason
MWAIT_INSTRUCTION rip 0x400387 info 0 0
CPU 0/KVM-7301 [015] d... 1534719.099574: kvm_entry: vcpu 0
2) cpu: E5-2620 v3 and E5-2690 v4 (both hardwares support MONITOR/MWAIT)
This...
CPU 0/KVM-1683 [017] .... 4844125.856164: kvm_exit: reason EXCEPTION_NMI
rip 0x400382 info 0 80000306
CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_emulate_insn: 0:400382:0f
01 c9 (prot64)
CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_inj_exception: #UD (0x0)
CPU 0/KVM-1683 [017] d... 4844125.856167: kvm_entry: vcpu 0
and the kvm-unit-test guest reported:
Unhandled exception 6 #UD at ip 0000000000400387
error_code=0000 rflags=00010002 cs=00000008
rax=0000000000000000 rcx=0000000000000000 rdx=0000000200000000 rbx=0000000000000000
rbp=000000000044db60 rsi=0000000000000001 rdi=0000000000004020
r8=000000000000000a r9=00000000000003f8 r10=000000000044d1e2 r11=000000000044d1e1
r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
cr0=0000000080010011 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000000020
cr8=0000000000000000
STACK: @400387 40028f
0x0000000000400387: mwait at x86/perf_exit.c:17
/* "mwait %eax, %ecx;" */
> asm volatile(".byte 0x0f, 0x01, 0xc9;"
:: "a" (eax), "c" (ecx));
(inlined by) main at x86/perf_exit.c:93
mb();
> mwait(0, 0);
mb();
0x000000000040028e: start64 at x86/cstart64.S:206
lea __argv(%rip), %rsi
> call main
mov %eax, %edi
In result 2, the trace shows that vcpu is in 64bit protect-mode (the testcase
didn't jump to ring3 manually, so it's in ring0), as intel vol2 said the MWAIT
will #UD in this situation when:
#UD If the current privilege level is not 0.
If CPUID.01H:ECX.MONITOR[bit 3] = 0.
I think CPUID.01H:ECX.MONITOR does not matter, so I'm so curious about the
result 2 .
Do you have any idea ? Thanks.
PS: Wanpeng tested this on his laptop (maybe the cpu is Core-i7) and it worked
well as result 1.
kvm version : 4.4.11
host kernel : 3.10
The testcase is:
#include "libcflat.h"
#include "smp.h"
#include "vm.h"
#include "processor.h"
#include "desc.h"
#include "apic.h"
#include "apic-defs.h"
#include "asm/barrier.h"
[...]
static inline void mwait(unsigned long eax, unsigned long ecx)
{
/* "mwait %eax, %ecx;" */
asm volatile(".byte 0x0f, 0x01, 0xc9;"
:: "a" (eax), "c" (ecx));
}
[...]
int main(int argc, char **argv)
{
setup_vm();
smp_init();
while (test_cnt--) {
[...]
mwait(0, 0);
[...]
}
[...]
}
--
Regards,
Longpeng(Mike)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ help ] vcpu handle MWAIT different
2017-06-09 3:47 [ help ] vcpu handle MWAIT different Longpeng (Mike)
@ 2017-06-09 3:52 ` Longpeng (Mike)
2017-06-09 4:51 ` Nadav Amit
0 siblings, 1 reply; 4+ messages in thread
From: Longpeng (Mike) @ 2017-06-09 3:52 UTC (permalink / raw)
To: Radim Krčmář, Paolo Bonzini, Wanpeng Li
Cc: kvm, Michael S. Tsirkin, Gonglei
On 2017/6/9 11:47, Longpeng (Mike) wrote:
> Hi guys,
>
> I wrote a testcase which repeat execute MWAIT insn in kvm-unit-test and I tested
> it on different hardware, but got different results.
>
>
> 1) cpu: E5620 (hardware don't support MONITOR/MWAIT)
>
> This works well because I saw the following info in trace:
>
> CPU 0/KVM-7301 [015] .... 1534719.099573: kvm_exit: reason
> MWAIT_INSTRUCTION rip 0x400387 info 0 0
> CPU 0/KVM-7301 [015] d... 1534719.099573: kvm_entry: vcpu 0
> CPU 0/KVM-7301 [015] .... 1534719.099574: kvm_exit: reason
> MWAIT_INSTRUCTION rip 0x400387 info 0 0
> CPU 0/KVM-7301 [015] d... 1534719.099574: kvm_entry: vcpu 0
>
>
> 2) cpu: E5-2620 v3 and E5-2690 v4 (both hardwares support MONITOR/MWAIT)
>
> This...
>
> CPU 0/KVM-1683 [017] .... 4844125.856164: kvm_exit: reason EXCEPTION_NMI
> rip 0x400382 info 0 80000306
> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_emulate_insn: 0:400382:0f
> 01 c9 (prot64)
> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_inj_exception: #UD (0x0)
> CPU 0/KVM-1683 [017] d... 4844125.856167: kvm_entry: vcpu 0
>
Sorry, I made a mistake, the trace of result 2 is:
CPU 0/KVM-14333 [017] .... 4842658.749717: kvm_exit: reason EXCEPTION_NMI
rip 0x400387 info 0 80000306
CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_emulate_insn: 0:400387:0f
01 c9 (prot64)
CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_inj_exception: #UD (0x0)
CPU 0/KVM-14333 [017] d... 4842658.749720: kvm_entry: vcpu 0
> and the kvm-unit-test guest reported:
>
> Unhandled exception 6 #UD at ip 0000000000400387
> error_code=0000 rflags=00010002 cs=00000008
> rax=0000000000000000 rcx=0000000000000000 rdx=0000000200000000 rbx=0000000000000000
> rbp=000000000044db60 rsi=0000000000000001 rdi=0000000000004020
> r8=000000000000000a r9=00000000000003f8 r10=000000000044d1e2 r11=000000000044d1e1
> r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
> cr0=0000000080010011 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000000020
> cr8=0000000000000000
> STACK: @400387 40028f
> 0x0000000000400387: mwait at x86/perf_exit.c:17
> /* "mwait %eax, %ecx;" */
> > asm volatile(".byte 0x0f, 0x01, 0xc9;"
> :: "a" (eax), "c" (ecx));
> (inlined by) main at x86/perf_exit.c:93
> mb();
> > mwait(0, 0);
> mb();
> 0x000000000040028e: start64 at x86/cstart64.S:206
> lea __argv(%rip), %rsi
> > call main
> mov %eax, %edi
>
> In result 2, the trace shows that vcpu is in 64bit protect-mode (the testcase
> didn't jump to ring3 manually, so it's in ring0), as intel vol2 said the MWAIT
> will #UD in this situation when:
>
> #UD If the current privilege level is not 0.
> If CPUID.01H:ECX.MONITOR[bit 3] = 0.
>
> I think CPUID.01H:ECX.MONITOR does not matter, so I'm so curious about the
> result 2 .
>
> Do you have any idea ? Thanks.
>
> PS: Wanpeng tested this on his laptop (maybe the cpu is Core-i7) and it worked
> well as result 1.
>
> kvm version : 4.4.11
> host kernel : 3.10
>
>
> The testcase is:
>
> #include "libcflat.h"
> #include "smp.h"
> #include "vm.h"
> #include "processor.h"
> #include "desc.h"
> #include "apic.h"
> #include "apic-defs.h"
> #include "asm/barrier.h"
>
> [...]
>
> static inline void mwait(unsigned long eax, unsigned long ecx)
> {
> /* "mwait %eax, %ecx;" */
> asm volatile(".byte 0x0f, 0x01, 0xc9;"
> :: "a" (eax), "c" (ecx));
> }
>
> [...]
>
> int main(int argc, char **argv)
> {
> setup_vm();
> smp_init();
>
> while (test_cnt--) {
> [...]
> mwait(0, 0);
> [...]
> }
> [...]
> }
>
>
--
Regards,
Longpeng(Mike)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ help ] vcpu handle MWAIT different
2017-06-09 3:52 ` Longpeng (Mike)
@ 2017-06-09 4:51 ` Nadav Amit
2017-06-09 5:57 ` Longpeng (Mike)
0 siblings, 1 reply; 4+ messages in thread
From: Nadav Amit @ 2017-06-09 4:51 UTC (permalink / raw)
To: Longpeng (Mike)
Cc: Radim Krčmář, Paolo Bonzini, Wanpeng Li, kvm,
Michael S. Tsirkin, Gonglei
Maybe you disabled MWAIT it in the BIOS. Try to read IA32_MISC_ENABLE[18]
(MSR 0x1a0). If it is clear, MWAIT/MONITOR is disabled.
> On Jun 8, 2017, at 8:52 PM, Longpeng (Mike) <longpeng2@huawei.com> wrote:
>
>
> On 2017/6/9 11:47, Longpeng (Mike) wrote:
>
>> Hi guys,
>>
>> I wrote a testcase which repeat execute MWAIT insn in kvm-unit-test and I tested
>> it on different hardware, but got different results.
>>
>>
>> 1) cpu: E5620 (hardware don't support MONITOR/MWAIT)
>>
>> This works well because I saw the following info in trace:
>>
>> CPU 0/KVM-7301 [015] .... 1534719.099573: kvm_exit: reason
>> MWAIT_INSTRUCTION rip 0x400387 info 0 0
>> CPU 0/KVM-7301 [015] d... 1534719.099573: kvm_entry: vcpu 0
>> CPU 0/KVM-7301 [015] .... 1534719.099574: kvm_exit: reason
>> MWAIT_INSTRUCTION rip 0x400387 info 0 0
>> CPU 0/KVM-7301 [015] d... 1534719.099574: kvm_entry: vcpu 0
>>
>>
>> 2) cpu: E5-2620 v3 and E5-2690 v4 (both hardwares support MONITOR/MWAIT)
>>
>> This...
>>
>> CPU 0/KVM-1683 [017] .... 4844125.856164: kvm_exit: reason EXCEPTION_NMI
>> rip 0x400382 info 0 80000306
>> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_emulate_insn: 0:400382:0f
>> 01 c9 (prot64)
>> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_inj_exception: #UD (0x0)
>> CPU 0/KVM-1683 [017] d... 4844125.856167: kvm_entry: vcpu 0
>>
>
>
> Sorry, I made a mistake, the trace of result 2 is:
>
> CPU 0/KVM-14333 [017] .... 4842658.749717: kvm_exit: reason EXCEPTION_NMI
> rip 0x400387 info 0 80000306
> CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_emulate_insn: 0:400387:0f
> 01 c9 (prot64)
> CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_inj_exception: #UD (0x0)
> CPU 0/KVM-14333 [017] d... 4842658.749720: kvm_entry: vcpu 0
>
>
>> and the kvm-unit-test guest reported:
>>
>> Unhandled exception 6 #UD at ip 0000000000400387
>> error_code=0000 rflags=00010002 cs=00000008
>> rax=0000000000000000 rcx=0000000000000000 rdx=0000000200000000 rbx=0000000000000000
>> rbp=000000000044db60 rsi=0000000000000001 rdi=0000000000004020
>> r8=000000000000000a r9=00000000000003f8 r10=000000000044d1e2 r11=000000000044d1e1
>> r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
>> cr0=0000000080010011 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000000020
>> cr8=0000000000000000
>> STACK: @400387 40028f
>> 0x0000000000400387: mwait at x86/perf_exit.c:17
>> /* "mwait %eax, %ecx;" */
>>> asm volatile(".byte 0x0f, 0x01, 0xc9;"
>> :: "a" (eax), "c" (ecx));
>> (inlined by) main at x86/perf_exit.c:93
>> mb();
>>> mwait(0, 0);
>> mb();
>> 0x000000000040028e: start64 at x86/cstart64.S:206
>> lea __argv(%rip), %rsi
>>> call main
>> mov %eax, %edi
>>
>> In result 2, the trace shows that vcpu is in 64bit protect-mode (the testcase
>> didn't jump to ring3 manually, so it's in ring0), as intel vol2 said the MWAIT
>> will #UD in this situation when:
>>
>> #UD If the current privilege level is not 0.
>> If CPUID.01H:ECX.MONITOR[bit 3] = 0.
>>
>> I think CPUID.01H:ECX.MONITOR does not matter, so I'm so curious about the
>> result 2 .
>>
>> Do you have any idea ? Thanks.
>>
>> PS: Wanpeng tested this on his laptop (maybe the cpu is Core-i7) and it worked
>> well as result 1.
>>
>> kvm version : 4.4.11
>> host kernel : 3.10
>>
>>
>> The testcase is:
>>
>> #include "libcflat.h"
>> #include "smp.h"
>> #include "vm.h"
>> #include "processor.h"
>> #include "desc.h"
>> #include "apic.h"
>> #include "apic-defs.h"
>> #include "asm/barrier.h"
>>
>> [...]
>>
>> static inline void mwait(unsigned long eax, unsigned long ecx)
>> {
>> /* "mwait %eax, %ecx;" */
>> asm volatile(".byte 0x0f, 0x01, 0xc9;"
>> :: "a" (eax), "c" (ecx));
>> }
>>
>> [...]
>>
>> int main(int argc, char **argv)
>> {
>> setup_vm();
>> smp_init();
>>
>> while (test_cnt--) {
>> [...]
>> mwait(0, 0);
>> [...]
>> }
>> [...]
>> }
>>
>>
>
>
> --
> Regards,
> Longpeng(Mike)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ help ] vcpu handle MWAIT different
2017-06-09 4:51 ` Nadav Amit
@ 2017-06-09 5:57 ` Longpeng (Mike)
0 siblings, 0 replies; 4+ messages in thread
From: Longpeng (Mike) @ 2017-06-09 5:57 UTC (permalink / raw)
To: Nadav Amit
Cc: Radim Krčmář, Paolo Bonzini, Wanpeng Li, kvm,
Michael S. Tsirkin, Gonglei
Hi Nadav,
Thanks for your suggestion, you're right.
I checked my hardwares, the E5620/E5-2620 v3/E5-2690 v4 all support
MONITOR/MWAIT, but my E5-2620 server and E5-2690 server disable MWAIT in the
BIOS, and E5620 server enable. So I made a mistake, sorry guys.
--
Regards,
Longpeng(Mike)
On 2017/6/9 12:51, Nadav Amit wrote:
> Maybe you disabled MWAIT it in the BIOS. Try to read IA32_MISC_ENABLE[18]
> (MSR 0x1a0). If it is clear, MWAIT/MONITOR is disabled.
>
>
>
>
>> On Jun 8, 2017, at 8:52 PM, Longpeng (Mike) <longpeng2@huawei.com> wrote:
>>
>>
>> On 2017/6/9 11:47, Longpeng (Mike) wrote:
>>
>>> Hi guys,
>>>
>>> I wrote a testcase which repeat execute MWAIT insn in kvm-unit-test and I tested
>>> it on different hardware, but got different results.
>>>
>>>
>>> 1) cpu: E5620 (hardware don't support MONITOR/MWAIT)
>>>
>>> This works well because I saw the following info in trace:
>>>
>>> CPU 0/KVM-7301 [015] .... 1534719.099573: kvm_exit: reason
>>> MWAIT_INSTRUCTION rip 0x400387 info 0 0
>>> CPU 0/KVM-7301 [015] d... 1534719.099573: kvm_entry: vcpu 0
>>> CPU 0/KVM-7301 [015] .... 1534719.099574: kvm_exit: reason
>>> MWAIT_INSTRUCTION rip 0x400387 info 0 0
>>> CPU 0/KVM-7301 [015] d... 1534719.099574: kvm_entry: vcpu 0
>>>
>>>
>>> 2) cpu: E5-2620 v3 and E5-2690 v4 (both hardwares support MONITOR/MWAIT)
>>>
>>> This...
>>>
>>> CPU 0/KVM-1683 [017] .... 4844125.856164: kvm_exit: reason EXCEPTION_NMI
>>> rip 0x400382 info 0 80000306
>>> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_emulate_insn: 0:400382:0f
>>> 01 c9 (prot64)
>>> CPU 0/KVM-1683 [017] .... 4844125.856166: kvm_inj_exception: #UD (0x0)
>>> CPU 0/KVM-1683 [017] d... 4844125.856167: kvm_entry: vcpu 0
>>>
>>
>>
>> Sorry, I made a mistake, the trace of result 2 is:
>>
>> CPU 0/KVM-14333 [017] .... 4842658.749717: kvm_exit: reason EXCEPTION_NMI
>> rip 0x400387 info 0 80000306
>> CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_emulate_insn: 0:400387:0f
>> 01 c9 (prot64)
>> CPU 0/KVM-14333 [017] .... 4842658.749719: kvm_inj_exception: #UD (0x0)
>> CPU 0/KVM-14333 [017] d... 4842658.749720: kvm_entry: vcpu 0
>>
>>
>>> and the kvm-unit-test guest reported:
>>>
>>> Unhandled exception 6 #UD at ip 0000000000400387
>>> error_code=0000 rflags=00010002 cs=00000008
>>> rax=0000000000000000 rcx=0000000000000000 rdx=0000000200000000 rbx=0000000000000000
>>> rbp=000000000044db60 rsi=0000000000000001 rdi=0000000000004020
>>> r8=000000000000000a r9=00000000000003f8 r10=000000000044d1e2 r11=000000000044d1e1
>>> r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
>>> cr0=0000000080010011 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000000020
>>> cr8=0000000000000000
>>> STACK: @400387 40028f
>>> 0x0000000000400387: mwait at x86/perf_exit.c:17
>>> /* "mwait %eax, %ecx;" */
>>>> asm volatile(".byte 0x0f, 0x01, 0xc9;"
>>> :: "a" (eax), "c" (ecx));
>>> (inlined by) main at x86/perf_exit.c:93
>>> mb();
>>>> mwait(0, 0);
>>> mb();
>>> 0x000000000040028e: start64 at x86/cstart64.S:206
>>> lea __argv(%rip), %rsi
>>>> call main
>>> mov %eax, %edi
>>>
>>> In result 2, the trace shows that vcpu is in 64bit protect-mode (the testcase
>>> didn't jump to ring3 manually, so it's in ring0), as intel vol2 said the MWAIT
>>> will #UD in this situation when:
>>>
>>> #UD If the current privilege level is not 0.
>>> If CPUID.01H:ECX.MONITOR[bit 3] = 0.
>>>
>>> I think CPUID.01H:ECX.MONITOR does not matter, so I'm so curious about the
>>> result 2 .
>>>
>>> Do you have any idea ? Thanks.
>>>
>>> PS: Wanpeng tested this on his laptop (maybe the cpu is Core-i7) and it worked
>>> well as result 1.
>>>
>>> kvm version : 4.4.11
>>> host kernel : 3.10
>>>
>>>
>>> The testcase is:
>>>
>>> #include "libcflat.h"
>>> #include "smp.h"
>>> #include "vm.h"
>>> #include "processor.h"
>>> #include "desc.h"
>>> #include "apic.h"
>>> #include "apic-defs.h"
>>> #include "asm/barrier.h"
>>>
>>> [...]
>>>
>>> static inline void mwait(unsigned long eax, unsigned long ecx)
>>> {
>>> /* "mwait %eax, %ecx;" */
>>> asm volatile(".byte 0x0f, 0x01, 0xc9;"
>>> :: "a" (eax), "c" (ecx));
>>> }
>>>
>>> [...]
>>>
>>> int main(int argc, char **argv)
>>> {
>>> setup_vm();
>>> smp_init();
>>>
>>> while (test_cnt--) {
>>> [...]
>>> mwait(0, 0);
>>> [...]
>>> }
>>> [...]
>>> }
>>>
>>>
>>
>>
>> --
>> Regards,
>> Longpeng(Mike)
>
>
> .
>
--
Regards,
Longpeng(Mike)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-06-09 6:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-09 3:47 [ help ] vcpu handle MWAIT different Longpeng (Mike)
2017-06-09 3:52 ` Longpeng (Mike)
2017-06-09 4:51 ` Nadav Amit
2017-06-09 5:57 ` Longpeng (Mike)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.