Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754069AbdDLOeV (ORCPT ); Wed, 12 Apr 2017 10:34:21 -0400 Received: from mail-wr0-f175.google.com ([209.85.128.175]:35517 "EHLO mail-wr0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752932AbdDLOeS (ORCPT ); Wed, 12 Apr 2017 10:34:18 -0400 MIME-Version: 1.0 In-Reply-To: <4622E361-52AB-40F2-9915-45C48F0DBCD2@suse.de> References: <1491911135-216950-1-git-send-email-agraf@suse.de> <4622E361-52AB-40F2-9915-45C48F0DBCD2@suse.de> From: Jim Mattson Date: Wed, 12 Apr 2017 07:34:06 -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: 2002 Lines: 41 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... Since we're still not going to report MONITOR support in CPUID, the only guests of consequence are paravirtual guests. What if a 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. 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. On Tue, Apr 11, 2017 at 11:23 AM, Alexander Graf wrote: > > >> Am 11.04.2017 um 19:10 schrieb Jim Mattson : >> >> This might be more useful if it could be dynamically toggled on and >> off, depending on system load. > > What would trapping mwait (currently) buy you? > > As it stands today, before this patch, mwait is simply implemented as a nop, so enabling the trap just means you're wasting as much cpu time, but never send the pCPU idle. With this patch, the CPU at least has the chance to go idle. > > Keep in mind that this patch does *not* advertise the mwait cpuid feature bit to the guest. > > What you're referring to I guess is actual mwait emulation. That is indeed more useful, but a bigger patch than this and needs some more thought on how to properly cache the monitor'ed pages. > > > Alex > >