From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gabriel L. Somlo" Subject: Re: [PATCH v2] kvm: x86: emulate monitor and mwait instructions as nop Date: Thu, 5 Jun 2014 17:19:42 -0400 Message-ID: <20140605211941.GA16157@ERROL.INI.CMU.EDU> References: <20140507205210.GA30030@ERROL.INI.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: KVM , "Michael S. Tsirkin" , Paolo Bonzini , afaerber@suse.de, Alexander Graf To: Eric Northup Return-path: Received: from mail-qg0-f43.google.com ([209.85.192.43]:36289 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751589AbaFEVTs (ORCPT ); Thu, 5 Jun 2014 17:19:48 -0400 Received: by mail-qg0-f43.google.com with SMTP id 63so2694715qgz.2 for ; Thu, 05 Jun 2014 14:19:47 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 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