linux-kernel - Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Apr 2017 15:15:41 +0200
From:   Alexander Graf <agraf@...e.de>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     Jim Mattson <jmattson@...gle.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Gabriel L. Somlo" <gsomlo@...il.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Joerg Roedel <joro@...tes.org>, kvm list <kvm@...r.kernel.org>,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 04/04/2017 03:13 PM, Radim Krčmář wrote:
> 2017-04-04 14:51+0200, Alexander Graf:
>> On 04/04/2017 02:39 PM, Radim Krčmář wrote:
>>> 2017-04-03 12:04+0200, Alexander Graf:
>>>> So coming back to the original patch, is there anything that should keep us
>>>> from exposing MWAIT straight into the guest at all times?
>>> Just minor issues:
>>>    * OS X on Core 2 fails for unknown reason if we disable the instruction
>>>      trapping, which is an argument against doing it by default
>> So for that we should try and see if changing the exposed CPUID MWAIT leaf
>> helps. Currently we return 0/0 which is pretty bogus and might be the reason
>> OSX fails.
> We have tried to pass host's CPUID MWAIT leaf and it still failed:
> https://www.spinics.net/lists/kvm/msg146686.html
>
> I wouldn't mind breaking that particular combination of OS X and
> hardware, but I'm worried to do it because we don't understand why it
> broke, so there could be more ...
>
>>>    * idling guests would consume host CPU, which is a significant change
>>>      in behavior and shouldn't be done without userspace's involvement
>> That's the same as today, as idling guests with MWAIT would also today end
>> up in a NOP emulated loop.
>>
>> Please bear in mind that I do not advocate to expose the MWAIT CPUID flag.
>> This is only for the instruction trap.
> Ah, makes sense.
>
>>> I think the best compromise is to add a capability for the MWAIT VM-exit
>>> controls and let userspace expose MWAIT if it wishes to.
>>> Will send a patch.
>> Please see my patch to force enable CPUID bits ;).
> Nice.  MWAIT could also use setting of arbitrary values for its leaf,
> but a generic interface for that would probably look clunky on the
> command line ...


I think we should have an interface similar to smbios for that 
eventually. Something where you can explicitly set arbitrary CPUID leaf 
information using leaf specific syntax. There are more leafs where it 
would make sense - cache topology for example.


Alex