From patchwork Thu Mar 16 17:22:44 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: 9629065 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 3CA026048C for ; Thu, 16 Mar 2017 17:23:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2D0EB2844E for ; Thu, 16 Mar 2017 17:23:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 21C162860C; Thu, 16 Mar 2017 17:23:50 +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=unavailable 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 C22182844E for ; Thu, 16 Mar 2017 17:23:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753008AbdCPRX2 (ORCPT ); Thu, 16 Mar 2017 13:23:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45724 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751841AbdCPRWv (ORCPT ); Thu, 16 Mar 2017 13:22:51 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5DE69C05166A; Thu, 16 Mar 2017 17:22:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5DE69C05166A Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5DE69C05166A Received: from potion (dhcp-1-208.brq.redhat.com [10.34.1.208]) by smtp.corp.redhat.com (Postfix) with SMTP id 6297319E6A; Thu, 16 Mar 2017 17:22:46 +0000 (UTC) Received: by potion (sSMTP sendmail emulation); Thu, 16 Mar 2017 18:22:44 +0100 Date: Thu, 16 Mar 2017 18:22:44 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: "Gabriel L. Somlo" Cc: "Michael S. Tsirkin" , linux-kernel@vger.kernel.org, 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: <20170316172243.GE14076@potion> References: <1489612895-12799-1-git-send-email-mst@redhat.com> <20170315233534.GG2239@HEDWIG.INI.CMU.EDU> <20170316013903-mutt-send-email-mst@kernel.org> <20170316132426.GB4085@HEDWIG.INI.CMU.EDU> <20170316155550-mutt-send-email-mst@kernel.org> <20170316145819.GC4085@HEDWIG.INI.CMU.EDU> <20170316153517.GL14081@potion> <20170316160157.GN14081@potion> <20170316164749.GG4085@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170316164749.GG4085@HEDWIG.INI.CMU.EDU> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 16 Mar 2017 17:22:51 +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-16 12:47-0400, Gabriel L. Somlo: > On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote: > > 2017-03-16 16:35+0100, Radim Krčmář: > > > 2017-03-16 10:58-0400, Gabriel L. Somlo: > > >> The intel manual said the same thing back in 2010 as well. However, > > >> regardless of how any flags were set, interrupt-window exiting or not, > > >> "normal" L1 MWAIT behavior was that it woke up immediately regardless. > > >> Remember, never going to sleep is still correct ("normal" ?) behavior > > >> per the ISA definition of MWAIT :) > > > > > > I'll write a simple kvm-unit-test to better understand why it is broken > > > for you ... > > > > Please get git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git > > > > and try this, thanks! > > > > ---8<--- > > x86/mwait: crappy test > > > > `./configure && make` to build it, then follow the comment in code to > > try few cases. > > kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 1 1' > timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -kernel x86/mwait.flat -append 0 1 1 > enabling apic > PASS: resumed from mwait 10000 times > SUMMARY: 1 tests > > real 0m10.564s > user 0m10.339s > sys 0m0.225s > > > and > > kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 1 0' > timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -kernel x86/mwait.flat -append 0 1 0 > enabling apic > PASS: resumed from mwait 10000 times > SUMMARY: 1 tests > > real 0m0.746s > user 0m0.555s > sys 0m0.200s > > Both of these with Michael's v5 patch applied, on the MacPro1,1. > > Similar behavior (0 1 1 takes 10 seconds, 0 1 0 returns immediately) > on the macbook air. > > If I revert to the original (nop-emulated MWAIT) kvm source, I get > both versions to return immediately. Those look normal ... maybe MWAIT just ignores writes to the monitored area? Please apply the patch below and following and try: time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 1 1' -smp 2 time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 0 1' -smp 2 time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 0 0' -smp 2 All of them should take rougly the same time as the NOP one, time TIMEOUT=20 ./x86-run x86/mwait.flat -append '0 1 0' -smp 2 Thanks. ---8<--- diff --git a/x86/mwait.c b/x86/mwait.c index c21dab5cc97d..ca38e7223596 100644 --- a/x86/mwait.c +++ b/x86/mwait.c @@ -1,7 +1,9 @@ #include "vm.h" +#include "smp.h" #define TARGET_RESUMES 10000 volatile unsigned page[4096 / 4]; +volatile unsigned resumes; /* * Execute @@ -18,19 +20,39 @@ volatile unsigned page[4096 / 4]; * Getting killed by the TIMEOUT most likely means that you have different HZ, * but could also be a bug ... */ +void writer(void *null) +{ + int i; + unsigned old_resumes = 0, new_resumes; + + for (i = 0; i < TARGET_RESUMES; i++) { + (*page)++; + + while (old_resumes == (new_resumes = resumes)) + pause(); + old_resumes = new_resumes; + } +} + int main(int argc, char **argv) { uint32_t eax = atol(argv[1]); uint32_t ecx = atol(argv[2]); bool sti = atol(argv[3]); - unsigned resumes = 0; + bool smp; + + smp_init(); + smp = cpu_count() > 1; + + if (smp) + on_cpu_async(1, writer, NULL); if (sti) asm volatile ("sti"); else asm volatile ("cli"); - while (resumes < TARGET_RESUMES) { + while ((smp ? *page : resumes) < TARGET_RESUMES) { asm volatile("monitor" :: "a" (page), "c" (0), "d" (0)); asm volatile("mwait" :: "a" (eax), "c" (ecx)); resumes++;