From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: linux-kernel@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Joerg Roedel" <joro@8bytes.org>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests
Date: Thu, 16 Mar 2017 01:41:28 +0200 [thread overview]
Message-ID: <20170316013903-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170315233534.GG2239@HEDWIG.INI.CMU.EDU>
On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> On Wed, Mar 15, 2017 at 11:22:18PM +0200, Michael S. Tsirkin wrote:
> > Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
> > unless explicitly provided with kernel command line argument
> > "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
> > without checking CPUID.
> >
> > We currently emulate that as a NOP but on VMX we can do better: let
> > guest stop the CPU until timer, IPI or memory change. CPU will be busy
> > but that isn't any worse than a NOP emulation.
> >
> > Note that mwait within guests is not the same as on real hardware
> > because halt causes an exit while mwait doesn't. For this reason it
> > might not be a good idea to use the regular MWAIT flag in CPUID to
> > signal this capability. Add a flag in the hypervisor leaf instead.
> >
> > Additionally, we add a capability for QEMU - e.g. if it knows there's an
> > isolated CPU dedicated for the VCPU it can set the standard MWAIT flag
> > to improve guest behaviour.
>
> Same behavior (on the mac pro 1,1 running F22 with custom-compiled
> kernel from kvm git master, plus this patch on top).
>
> The OS X 10.7 kernel hangs (or at least progresses extremely slowly)
> on boot, does not bring up guest graphical interface within the first
> 10 minutes that I waited for it. That, in contrast with the default
> nop-based emulation where the guest comes up within 30 seconds.
Thanks a lot, meanwhile I'll try to write a unit-test and experiment
with various behaviours.
> I will run another round of tests on a newer Mac (4-year-old macbook
> air) and report back tomorrow.
>
> Going off on a tangent, why would encouraging otherwise well-behaved
> guests (like linux ones, for example) to use MWAIT be desirable to
> begin with ? Is it a matter of minimizing the overhead associated with
> exiting and re-entering L1 ? Because if so, AFAIR staying inside L1 and
> running guest-mode MWAIT in a tight loop will actually waste the host
> CPU without the opportunity to yield to some other L0 thread. Sorry if
> I fell into the middle of an ongoing conversation on this and missed
> most of the relevant context, in which case please feel free to ignore
> me... :)
>
> Thanks,
> --G
It's just some experiments I'm running, I'm not ready to describe it
yet. I thought this part might be useful to at least some guests, so
trying to upstream it right now.
--
MST
next prev parent reply other threads:[~2017-03-15 23:41 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 21:22 [PATCH v5 untested] kvm: better MWAIT emulation for guests Michael S. Tsirkin
2017-03-15 23:35 ` Gabriel L. Somlo
2017-03-15 23:41 ` Michael S. Tsirkin [this message]
2017-03-16 13:24 ` Gabriel L. Somlo
2017-03-16 14:04 ` Michael S. Tsirkin
2017-03-16 14:58 ` Gabriel L. Somlo
2017-03-16 15:23 ` Michael S. Tsirkin
2017-03-16 15:35 ` Radim Krčmář
2017-03-16 16:01 ` Radim Krčmář
2017-03-16 16:47 ` Gabriel L. Somlo
2017-03-16 17:22 ` Radim Krčmář
2017-03-16 17:39 ` Gabriel L. Somlo
2017-03-16 17:27 ` Michael S. Tsirkin
2017-03-16 17:41 ` Gabriel L. Somlo
2017-03-16 18:29 ` Michael S. Tsirkin
2017-03-16 19:24 ` Gabriel L. Somlo
2017-03-16 19:27 ` Michael S. Tsirkin
2017-03-16 20:17 ` Gabriel L. Somlo
2017-03-16 21:14 ` Gabriel L. Somlo
2017-03-17 2:03 ` Michael S. Tsirkin
2017-03-17 13:23 ` Gabriel L. Somlo
2017-03-21 3:22 ` Michael S. Tsirkin
2017-03-21 16:58 ` Radim Krčmář
2017-03-21 17:29 ` Nadav Amit
2017-03-21 17:29 ` Nadav Amit
2017-03-21 19:22 ` Radim Krčmář
2017-03-21 22:51 ` Gabriel Somlo
2017-03-22 0:02 ` Nadav Amit
2017-03-22 13:35 ` Michael S. Tsirkin
2017-03-22 14:10 ` Gabriel L. Somlo
2017-03-22 14:15 ` Michael S. Tsirkin
2017-03-16 16:16 ` Gabriel L. Somlo
2017-03-16 16:45 ` Michael S. Tsirkin
2017-03-16 16:52 ` Gabriel L. Somlo
2017-03-16 16:54 ` Gabriel L. Somlo
2017-03-16 17:14 ` Michael S. Tsirkin
2017-03-16 17:38 ` Radim Krčmář
2017-03-16 14:08 ` Radim Krčmář
2017-03-16 15:44 ` Gabriel L. Somlo
2017-03-16 15:54 ` Radim Krčmář
2017-03-16 16:26 ` Gabriel L. Somlo
2017-03-21 16:16 ` Joerg Roedel
2017-03-21 18:45 ` Michael S. Tsirkin
2017-03-27 13:34 ` Alexander Graf
2017-03-28 14:28 ` Radim Krčmář
2017-03-28 20:35 ` Jim Mattson
2017-03-29 12:11 ` Radim Krčmář
2017-04-03 10:04 ` Alexander Graf
2017-04-04 12:39 ` Radim Krčmář
2017-04-04 12:51 ` Alexander Graf
2017-04-04 13:13 ` Radim Krčmář
2017-04-04 13:15 ` Alexander Graf
2017-04-04 13:44 ` Radim Krčmář
2017-04-04 13:44 ` [Qemu-devel] " Radim Krčmář
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=20170316013903-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=corbet@lwn.net \
--cc=gsomlo@gmail.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 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.