linux-kernel - Re: [PATCH v6] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <e6635b63-351f-584c-4805-316d44b10673@suse.de>
Date:   Tue, 11 Apr 2017 14:43:06 +0200
From:   Alexander Graf <agraf@...e.de>
To:     "Gabriel L. Somlo" <gsomlo@...il.com>
Cc:     kvm list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        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>, linux-doc@...r.kernel.org,
        qemu-devel@...gnu.org
Subject: Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 04/11/2017 02:41 PM, Gabriel L. Somlo wrote:
> On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote:
>> From: "Michael S. Tsirkin" <mst@...hat.com>
>>
>> Guests that are heavy on futexes end up IPI'ing each other a lot. That
>> can lead to significant slowdowns and latency increase for those guests
>> when running within KVM.
>>
>> If only a single guest is needed on a host, we have a lot of spare host
>> CPU time we can throw at the problem. Modern CPUs implement a feature
>> called "MWAIT" which allows guests to wake up sleeping remote CPUs without
>> an IPI - thus without an exit - at the expense of never going out of guest
>> context.
>>
>> The decision whether this is something sensible to use should be up to the
>> VM admin, so to user space. We can however allow MWAIT execution on systems
>> that support it properly hardware wise.
>>
>> This patch adds a CAP to user space and a KVM cpuid leaf to indicate
>> availability of native MWAIT execution. With that enabled, the worst a
>> guest can do is waste as many cycles as a "jmp ." would do, so it's not
>> a privilege problem.
> Did you mean "hlt" rather than "jmp" ?

No, hlt wouldn't waste cycles, "jmp ." does.

The point I'm trying to make here is that by removing the MWAIT trap we 
don't give the guest more CPU time than we would've granted it before.

>
>> We consciously do *not* expose the feature in our CPUID bitmap, as most
>> people will want to benefit from sleeping vCPUs to allow for over commit.
>>
>> Reported-by: "Gabriel L. Somlo" <gsomlo@...il.com>
> That's maybe a bit inacurate, I didn't actually report anything *this*
> patch is trying to address (that was rather commit 87c00572ba05aa8c9d).
>
> Maybe
>
> Acked-by: Gabriel Somlo <gsomlo@...il.com>
>
> would be a more accurate statement instead?

Works for me :). I'm sure whoever applies this can swizzle the tag?


Alex