> Am 02.06.2014 um 22:41 schrieb "Michael S. Tsirkin" <mst@xxxxxxxxxx>: > >> On Mon, Jun 02, 2014 at 10:35:56PM +0200, Alexander Graf wrote: >> >> >>>> Am 02.06.2014 um 22:20 schrieb "Michael S. Tsirkin" <mst@xxxxxxxxxx>: >>>> >>>> On Mon, Jun 02, 2014 at 09:48:19PM +0200, Alexander Graf wrote: >>>> >>>> >>>>>> Am 02.06.2014 um 21:25 schrieb "Gabriel L. Somlo" <gsomlo@xxxxxxxxx>: >>>>>> >>>>>> 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 <somlo@xxxxxxx> >>>>>> --- >>>>>> >>>>>> 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? User space can force cpuid bits that kvm doesn't return as supported, so we do have a negative-by-default switch. We also have an ENABLE_CAP ioctl. Enabling the monitor/mwait nop ability explicitly by that is a 5 line patch. Either way is very flexible and not system wide. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
