From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v2] kvm: x86: emulate monitor and mwait instructions as nop Date: Mon, 2 Jun 2014 23:41:28 +0300 Message-ID: <20140602204128.GA5791@redhat.com> References: <20140507205210.GA30030@ERROL.INI.CMU.EDU> <20140602192530.GC1653@ERROL.INI.CMU.EDU> <20140602202044.GA5676@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Gabriel L. Somlo" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "afaerber@suse.de" To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20918 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753391AbaFBUlD (ORCPT ); Mon, 2 Jun 2014 16:41:03 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 02, 2014 at 10:35:56PM +0200, Alexander Graf wrote: > > > > Am 02.06.2014 um 22:20 schrieb "Michael S. Tsirkin" : > > > >> On Mon, Jun 02, 2014 at 09:48:19PM +0200, Alexander Graf wrote: > >> > >> > >>>> Am 02.06.2014 um 21:25 schrieb "Gabriel L. Somlo" : > >>>> > >>>> On Wed, May 07, 2014 at 04:52:13PM -0400, 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. > >>>> > >>>> Signed-off-by: Gabriel L. Somlo > >>>> --- > >>>> > >>>> New in v2: remove invalid_op handler functions which were only used to > >>>> handle exits caused by monitor and mwait > >>>> > >>>>>> On Wed, May 07, 2014 at 08:31:27PM +0200, Alexander Graf wrote: > >>>>>> On 05/07/2014 08:15 PM, Michael S. Tsirkin wrote: > >>>>>> If we really want to be paranoid and worry about guests > >>>>>> that use this strange way to trigger invalid opcode, > >>>>>> we can make it possible for userspace to enable/disable > >>>>>> this hack, and teach qemu to set it. > >>>>>> > >>>>>> That would make it even safer than it was. > >>>>>> > >>>>>> Not sure it's worth it, just a thought. > >>>>> > >>>>> Since we don't trap on non-exposed other instructions (new SSE and > >>>>> whatdoiknow) I don't think it's really bad to just expose > >>>>> MONITOR/MWAIT as nops. > >>> > >>> Would it make sense to make this a module parameter, > >>> (e.g., "int emulate_mwait") ? > >>> > >>> Default would be 0 (no emulation). 1 would mean "emulate as nop", and > >>> if anyone ever figures out how to do proper page-locking based > >>> emulation we could use 2 to enable that, etc. ? > >>> > >>> Not sure we'd want qemu to enable/disable it automatically, though... > >>> > >>> What do you all think ? > >> > >> I don't like module parameters - they're system global and there's a good chance you want to run non-osx in parallel ;). > >> > >> I'd either link this to the cpuid bits or enable it forcefully through ENABLE_CAP per vcpu. > >> > >> Alex > > > > Point is that. > > Paolo here thinks it's safe to just make it a NOP unconditionally. > > so module parameter would be there as a debugging tool: > > as a means for users to test with old kvm behaviour if they see breakage. > > Which we don't expect, so no need to waste cycles creating a pretty > > interface for it. > > Both interfaces already exist, so where's the problem? Hmm sorry which interfaces for enabling mwait nop emulation exist? > I'm fine with making it always nop too though. > > Gabriel was asking how to make it switchable - and the only thing I'd nak is a module parameter because it's not useful. > > > Alex > -- MST