From: Alexander Graf <agraf@suse.de>
To: Wanpeng Li <kernellwp@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Wanpeng Li" <wanpeng.li@hotmail.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Gabriel L. Somlo" <gsomlo@gmail.com>
Subject: Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests
Date: Thu, 4 May 2017 11:43:31 +0200 [thread overview]
Message-ID: <32d54ba8-9b12-2b8e-0b0d-052b75ba1db0@suse.de> (raw)
In-Reply-To: <1493890648-9277-1-git-send-email-wanpeng.li@hotmail.com>
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
next prev parent reply other threads:[~2017-05-04 9:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 9:37 Wanpeng Li
2017-05-04 9:43 ` Alexander Graf [this message]
2017-05-04 10:37 ` Paolo Bonzini
2017-05-04 10:47 ` Wanpeng Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32d54ba8-9b12-2b8e-0b0d-052b75ba1db0@suse.de \
--to=agraf@suse.de \
--cc=gsomlo@gmail.com \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=wanpeng.li@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®