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

Gabriel L. Somlo
2014-06-05T21:19:48Z

On Thu, Jun 05, 2014 at 01:59:17PM -0700, Eric Northup wrote:
> On Wed, May 7, 2014 at 1:52 PM, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > Treat monitor and mwait instructions as nop, which is architecturally
> > correct (but inefficient) behavior. We do this to prevent misbehaving
> > guests (e.g. OS X <= 10.7) from crashing after they fail to check for
> > monitor/mwait availability via cpuid.
> >
> > Since mwait-based idle loops relying on these nop-emulated instructions
> > would keep the host CPU pegged at 100%, do NOT advertise their presence
> > via cpuid, to prevent compliant guests from using them inadvertently.
>
> If it's going to peg the host CPU at 100% anyway, why bother emulating
> it? Just let the guest run the mwait instruction! Have a condition
> that controls whether CPU_BASED_MWAIT_EXITING gets set in the VMCS
> processor execution controls. Go ahead and put it in CPUID, since
> it's actually allowed.

If a well-behaved guest *does* check CPUID, we want it to get a
negative answer and fall back to a HLT-based idle loop (rather than
use mwait and peg the host cpu to 100%).

We only emulate it so that guests which use it blindly, regardless of
what CPUID says (e.g., OS X 10.6 .. 10.8) would still run instead of
crashing with an invalid opcode fault. That is, work long enough for
someone to manually force a hlt-idle fallback on the guest-side by
removing System/Library/Extensions/AppleIntelCPUPowerManagement.kext :)

Causing a VM exit (as opposed to letting the MWAIT just be a NOP in VM
guest mode) is nice, since it allows us to try and do something more
fancy in the future (i.e. yield the host cpu instead of re-entering
immediately, or attempting to otherwise emulate the instruction in a
way that's "better").

Anyhow, my $0.02 :)

Cheers,
--Gabriel