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

Alexander Graf
2014-06-02T21:01:08Z

> Am 02.06.2014 um 22:41 schrieb "Michael S. Tsirkin" <mst@redhat.com>:
>
>> 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@redhat.com>:
>>>>
>>>> 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@gmail.com>:
>>>>>>
>>>>>> 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@cmu.edu>
>>>>>> ---
>>>>>>
>>>>>> 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