Re: [PATCH v2] kvm: x86: emulate monitor and mwait instructions as nop

Gabriel L. Somlo
2014-06-03T14:22:01Z

On Tue, Jun 03, 2014 at 11:17:48AM +0200, Paolo Bonzini wrote:
>
> I think it's fine as it is now. :)

On Mon, Jun 02, 2014 at 09:55:18PM -0400, Gabriel L. Somlo wrote:
>
> W.r.t. monitor/mwait, a guest can do one of the following:
>
> 1. Never check CPUID, and never use monitor/mwait
> - This is great, we don't have to do anything about these
>
> 2. Check CPUID for mwait, use it to idle in preference over hlt
> - Linux, Windows, and Mavericks (10.9) do this
> - we never want to have CPUID say "yes" to these, since
> monitor/mwait support will be clunky in the best case,
> and hlt is overwhelmingly preferable! [*]
>
> 3. Never check CPUID, use monitor/mwait with abandon
> - OS X 10.6 .. 10.8 does this
> - emulating monitor/mwait here allows us to boot the guest
> and use it, and perform sysadmin surgery to force a hlt
> based idle
>
> 4. Check CPUID, panic if unavailable
> - OS X 10.5 did this, IIRC.
> - whether I can do kext surgery and get it to stop checking
> CPUID *in addition to* falling back to hlt-based idle is
> TBD.
> - emulating monitor/mwait allows us to boot this type of
> guest, BUT WE ALSO HAVE TO ADVERTISE IT VIA CPUID !!!

As it is right now, #4 is not being addressed (and we can't just
advertise mwait via cpuid, or we'd be screwing up #2).

I also feel a bit weird about the "undocumented feature" aspect
of NOT generating an invalid opcode for something that *should*
be an invalid opcode according to the feature set advertised via
cpuid...

So if there's a way to make it so we can tell QEMU/KVM to
"--enable-mwait" on a per-guest basis, I think that'd be better
than an always-on "undocumented" behavior...

But then again, I'm most likely missing something about the big
picture... :)

Thanks much,
--Gabriel