From patchwork Tue Mar 21 19:22:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= X-Patchwork-Id: 9637457 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E6427601E9 for ; Tue, 21 Mar 2017 19:27:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D691D27C14 for ; Tue, 21 Mar 2017 19:27:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CB70E28304; Tue, 21 Mar 2017 19:27:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,HK_RANDOM_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 755952843F for ; Tue, 21 Mar 2017 19:27:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933783AbdCUT1R (ORCPT ); Tue, 21 Mar 2017 15:27:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59338 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933133AbdCUTZW (ORCPT ); Tue, 21 Mar 2017 15:25:22 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F198FC05AA59; Tue, 21 Mar 2017 19:22:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F198FC05AA59 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F198FC05AA59 Received: from potion (dhcp-1-208.brq.redhat.com [10.34.1.208]) by smtp.corp.redhat.com (Postfix) with SMTP id 9A5FB17A61; Tue, 21 Mar 2017 19:22:41 +0000 (UTC) Received: by potion (sSMTP sendmail emulation); Tue, 21 Mar 2017 20:22:39 +0100 Date: Tue, 21 Mar 2017 20:22:39 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Nadav Amit Cc: "Michael S. Tsirkin" , "Gabriel L. Somlo" , LKML , Paolo Bonzini , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Joerg Roedel , kvm@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests Message-ID: <20170321192239.GD25540@potion> References: <20170316202024-mutt-send-email-mst@kernel.org> <20170316192440.GL4085@HEDWIG.INI.CMU.EDU> <20170316212635-mutt-send-email-mst@kernel.org> <20170316201710.GN4085@HEDWIG.INI.CMU.EDU> <20170316211414.GO4085@HEDWIG.INI.CMU.EDU> <20170317035716-mutt-send-email-mst@kernel.org> <20170317132355.GA10906@HEDWIG.INI.CMU.EDU> <20170321052102-mutt-send-email-mst@kernel.org> <20170321165831.GC25540@potion> <15F4973A-9D7E-46B9-97B9-A431A756C272@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <15F4973A-9D7E-46B9-97B9-A431A756C272@gmail.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 21 Mar 2017 19:22:47 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 2017-03-21 10:29-0700, Nadav Amit: > > > On Mar 21, 2017, at 9:58 AM, Radim Krčmář wrote: > > > In '-smp 2', the writing VCPU always does 10000 wakeups by writing into > > monitored memory, but the mwaiting VCPU can be also woken up by host > > interrupts, which might add a few exits depending on timing. > > > > I didn't spend much time in making the PASS/FAIL mean much, or ensuring > > that we only get 10000 wakeups ... it is nothing to be worried about. > > > > Hint 240 behaves as nop even on my system, so I still don't find > > anything insane on that machine (if OS X is exluded) ... > > From my days in Intel (10 years ago), I can say that MWAIT wakes for many > microarchitecural events beside interrupts. > > Out of curiosity, aren’t you worried that on OS X the wbinvd causes an exit > after the monitor and before the mwait? VM entry clears the monitoring, so it should behave just like an MWAIT without MONITOR, which is NOP according to the spec. It does so on modern hardware, but it definitely is a good thing to try ... (I am worried about disabling MWAIT exits by default and it's a no-go until we understand why OS X doesn't work.) Gabriel, how does testing with this change behave on the old machine? Thanks. ---8<--- This should be the same as "wbinvd", because "wbinvd" does nothing without non-coherent vfio. Simply replacing "vmcall" with "wbinvd" is an option if the "vmcall" version works as expected. diff --git a/x86/mwait.c b/x86/mwait.c index 20f4dcbff8ae..19f988b94541 100644 --- a/x86/mwait.c +++ b/x86/mwait.c @@ -54,6 +54,7 @@ int main(int argc, char **argv) while ((smp ? *page : resumes) < TARGET_RESUMES) { asm volatile("monitor" :: "a" (page), "c" (0), "d" (0)); + asm volatile("vmcall" :: "a"(-1)); asm volatile("mwait" :: "a" (eax), "c" (ecx)); resumes++; }