Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754658AbdDLPU0 (ORCPT ); Wed, 12 Apr 2017 11:20:26 -0400 Received: from mail-wr0-f177.google.com ([209.85.128.177]:36177 "EHLO mail-wr0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752513AbdDLPUX (ORCPT ); Wed, 12 Apr 2017 11:20:23 -0400 MIME-Version: 1.0 In-Reply-To: <204f274d-697d-f9c6-8719-9bf91105f8b9@suse.de> References: <1491911135-216950-1-git-send-email-agraf@suse.de> <4622E361-52AB-40F2-9915-45C48F0DBCD2@suse.de> <204f274d-697d-f9c6-8719-9bf91105f8b9@suse.de> From: Jim Mattson Date: Wed, 12 Apr 2017 08:20:21 -0700 Message-ID: Subject: Re: [PATCH v6] kvm: better MWAIT emulation for guests To: Alexander Graf Cc: kvm list , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , "Michael S. Tsirkin" , LKML , "Gabriel L. Somlo" , Paolo Bonzini , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "the arch/x86 maintainers" , Joerg Roedel , linux-doc@vger.kernel.org, qemu-devel@nongnu.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2371 Lines: 60 On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote: > > > 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 :). This patch should be harmless. :-) > >> 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 ;). True. I don't have an easy solution to that problem. > >> 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. Yes, that would probably be the preferred solution. > > > > Alex