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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 12 Apr 2017 16:54:10 +0200
From:   Alexander Graf <agraf@...e.de>
To:     Jim Mattson <jmattson@...gle.com>
Cc:     kvm list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.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>, linux-doc@...r.kernel.org,
        qemu-devel@...gnu.org
Subject: Re: [PATCH v6] kvm: better MWAIT emulation for guests



On 12.04.17 16:34, Jim Mattson wrote:
> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
> monitor and mwait instructions as nop"), so when we intercept
> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from
> vanilla kvm that motivates the following idea...

So you're not running upstream kvm? In that case, you can just not take 
this patch either :).

> Since we're still not going to report MONITOR support in CPUID, the
> only guests of consequence are paravirtual guests. What if a

Only if someone actually implemented something for PV guests, yes.

The real motivation is to allow user space to force set the MONITOR 
CPUID flag. That way an admin can - if he really wants to - dedicate 
pCPUs to the VM.

I agree that we don't need the kvm pv flag for that. I'd be happy to 
drop that if everyone agrees.

> paravirtual guest was aware of the fact that sometimes MONITOR/MWAIT
> would work as architected, and sometimes they would raise #UD (or do
> something else that's guest-visible, to indicate that the hypevisor is
> intercepting the instructions). Such a guest could first try a
> MONITOR/MWAIT-based idle loop and then fall back on a HLT-based idle
> loop if the hypervisor rejected its use of MONITOR/MWAIT.

How would that work? That guest would have to atomically notify all 
other vCPUs that wakeup notifications now go via IPIs instead of cache 
line dirtying.

That's probably as much work to get right as it would be to just emulate 
MWAIT inside kvm ;).

> We already have the loose concept of "this pCPU has other things to
> do," which is encoded in the variable-sized PLE window. With
> MONITOR/MWAIT, the choice is binary, but a simple implementation could
> tie the two together, by allowing the guest to use MONITOR/MWAIT
> whenever the PLE window exceeds a certain threshold. Or the decision
> could be left to the userspace agent.

I agree, and that's basically the idea I mentioned earlier with MWAIT 
emulation. We could (for well behaved guests) switch between emulating 
MWAIT and running native MWAIT.



Alex