From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFF80C10F27 for ; Tue, 10 Mar 2020 19:16:32 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7E15321D56 for ; Tue, 10 Mar 2020 19:16:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E15321D56 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=m00nbsd.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:39022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBkMh-0000GU-Ie for qemu-devel@archiver.kernel.org; Tue, 10 Mar 2020 15:16:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39832) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBkLI-0007u9-SZ for qemu-devel@nongnu.org; Tue, 10 Mar 2020 15:15:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBkLH-0002tj-BM for qemu-devel@nongnu.org; Tue, 10 Mar 2020 15:15:04 -0400 Received: from smtpout1.mo804.mail-out.ovh.net ([79.137.123.220]:50109) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jBkLH-0002ou-51 for qemu-devel@nongnu.org; Tue, 10 Mar 2020 15:15:03 -0400 Received: from mxplan6.mail.ovh.net (unknown [10.108.4.11]) by mo804.mail-out.ovh.net (Postfix) with ESMTPS id 09EC02C4898B; Tue, 10 Mar 2020 20:14:59 +0100 (CET) Received: from m00nbsd.net (37.59.142.101) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 10 Mar 2020 20:14:59 +0100 To: Paolo Bonzini References: <20200206115731.13552-1-n54@gmx.com> <20200206213232.1918-1-n54@gmx.com> <20200206213232.1918-4-n54@gmx.com> <24fe7b93-8a34-e5d7-18b5-0f7607221ad3@redhat.com> From: Maxime Villard Autocrypt: addr=max@m00nbsd.net; keydata= mQINBFLj1VcBEADKvx0jUiiosyANtkt4hV+oOrhghLrxHugeYHG4Wf4kxxAYlaFTAj/9d1H0 8CPx6rYQZliEM942Li/haXGr8w6+KWELeF9l2Lk7TPu/znmIovlT5z9zgbyGUMR8D8m8vDFC 4WNCjd5Q+rxL6eV1SC+mJFnV1t4vDSguaWYWKCXo4BpOqFrZwbDyr1VTjVeeIT7iJEvLfmsn uM9/1AAbPAi/fCxFtMQjWPtj/lTRlfeu5fk6wAl1u4c0VjyNMz09ahrw+Xg2lMJh8uAos2T7 HZ9t6svQKyNUWNwl+1tReuTS6d+Fgnm8stIjt3k1k/zU+YruJ4u6y83/tw8wU8MXMviI962G RcPuBBUKV3ZfPfQ0qm13Mjac57v47n3hNFe1O9NInClu6bk9kUyiiL/qhYwvj0IHUQgRI+0n C9wIoqjjOWNfI/5u6yJWwQTDpdbH2NzD9pRKaOnRkSJRPaVnFXAPfFlDW2dWar+FynJZhW1c JKInGo2gGiogorrnkW4O14gTCVr40kT/LwzLVO7K1sAZsWhPoywj+9qv2SSEOczRkLS9en+2 XM4ISBokdv0ABKsJz667Gt4A9AvrffYDgXsAMif1UvbS12kDlV/6LcPj6BZxUgy2XGIAT5te N3Ad2cpC6AdYrkE6nWRtTnzfqA1wLPTXyh/eqi1aXK8RMrQxZwARAQABtCBNYXhpbWUgVmls bGFyZCA8bWF4QE0wMG5CU0QubmV0PokCOQQTAQIAIwUCUuPVVwIbAwcLCQgHAwIBBhUIAgkK CwQWAgMBAh4BAheAAAoJEEVwe6JOP4g3j/MP/2MNQQL7EobxHPFIep2CbQ92HZEiqj6EkU0O FnMj5QJUJASIT53d4tnc/fqTX3PHajmJIAB8hPRQOlnf1U1tU7yuCF1nr4cCm0qzBCWrhz8H 0vx4KbM05PWAFdZ5sLMNRch8bI0bYMsr/wYm1+nO3TYiYiKeeA/Uy+2CJkmHGze9rMYkv2bN +09za3en3F1vOAtpS6RjDbFtIOW7J5pIQXrEig+OnFVViOeIDulIRKSishgaJ07AC+nDOAvN HTC4OL7WvDntLSZt1486mJCb+fCueGj3jwL8z6SpPnWzxKchhw5+o0nTd7BivBPR1sE7NsCT VoYQQlWJIyDtmCJz5fu6h2ZggyDaGGwRBMTponp/unwz4f3jtx9z/uH0asWjPfzAE+EPHTqG W/MyEpjARN3jdEHH7jP1q/c9LYIKU9Jloae49bAkNYeg0p7Vjh3CJzmgNRZFEY/rHkVXlhEM VpFE+NpY5frunim1py27qDfnRIcfLZ1UnNizMY1X46qS0ZYzBgjSvo58c7uqef3ddfo/Z8iQ sJTX3EPK1T4un1DbDYm0oPLptj4yl4WDROuSiZa0+z1l/XhOXpaU4pbi+0e9Yt2tOm1W7n2v ALWhYisz2e63hUHgp1aPFHj0yt/+z2DXvBxK251Ts6c9SRunaJ4r6h0W2uWmA1P9g+0I6+O4 uQINBFLj1VcBEACj9g7q8r6eA6VaNrxJ5jcqZyXgQ0vgCEp8QqDl96EOt+grxJpyQKEEj1f4 1Qe3L4SL2CeIowZx1ilrOp6qASI/bZmOvNWYy6p9UfneK4ruHsP6TTBnQXiIV0H9jFblWvxC SSb5mh1tiF/sW4UOQzZd4jFvZR5mxCQxYtujFbL5Z8k1q3xcymlh7093sCMnaXUmX8Lc7My0 81u3dcR3Ko8Ku0HQLccBLXxHdM1k3a/LPZgT36dIMUdZDhEH4IJbLRTjk7d2sVEmj9v8/YIJ NaAlcBZcWIOBv29wbhGiwSpawtSTVE+0/aTRdRxWzCA59yo6aKWRg92WdtJoAobuzFPcImJG hC6K0/0n8J/BTO+Mn6FSa2TaIcR83WQ1byP9S7X4xwFw6SAv2LdTnTJH7tQ0c4FXEgqBJ+zI H6uu0rKuVzRFXCOVv1bKcfHxh2EoQPdG/G4f7gM8qXRCAXuG6MvvqIxCwpJf+5mOiA5ACHrw Ze92RG7/XdZTIdGnCCNCb6RHZT1B5Z+ZWsTSEuf2ZEytGBegSQTJ3HoRGqhUfHXGhNuQMM5m y7K6DLTq3PAcjbcjc1zYAeSitmdadZmgsjmGUKAz3qxFKp2khWovXr+4tAQN7bbSg46VbMmW /JquPrCv6t7IkkkFWRmWq7uhBZyX0nLYzXb6saMoG9aFdSnZQwARAQABiQIfBBgBAgAJBQJS 49VXAhsMAAoJEEVwe6JOP4g3+uIQAIDnZrjPwpzP986nhqngjLmR35nJ+9Q/GUiLgzFeNK8q uS/ScRSaI5unHUp7NWPXa+9nTR1RUFY1adD+Fg38C/J+cxn5jzGYScwGR/8JuWOZ6a1MebPA 29q/KhaiobH+CtX+N6kGxTaQpkytjJ1j3AeoXfxtCjXvIvStUqjupsss7E7LCc/TUzMnEHwt MbjO4q59/OaNZmt0k7f7USMyzMz5dBHSMeMAK2HAI8sBk13ZxLrLSCkt65KDYzW4U8CwZVcE aXuAfECGEHjvTpN+lIgYGT1heZuQeG+EoVDCW+QXTMNxSGOQpmA1zVsiK3h6qTF+bsJvt5tV 62fjUNbeqPaby58hiL0HuikPAgAPnPGejbrQesZbiaiiaEsNQkgJD6Dfo8hNTVGDMe/XiOCY V2vOh5BRxmVGG6660VBg1pY2SdpTmKYZyyPiSXXadU6LW2b/v/NLDBaydz5Jaxuf015f00bG 0FgxmAPd25zLJdm1Vcrnf4fvRZ9zTCq4rxzQXiMQMWH46RwTeSMobFovbDbP+//lwJ+WXAQM Ny29yyTGgywNyMZ76xogh1daV+ZHW/qgJQHnnU3ldcjDuC3fsi+uOBFGBbK/Kdw6pESw4oTT e70Ol6ljxgHHkXSffmHBduCdmruR+tZJ5nYasc1ZT7zUbOTjkdR6Fy+nlYZAszG8 Subject: Re: [PATCH v4 3/4] Introduce the NVMM impl Message-ID: <85e4202d-91dd-0d31-373a-febe566353ab@m00nbsd.net> Date: Tue, 10 Mar 2020 20:14:53 +0100 MIME-Version: 1.0 In-Reply-To: <24fe7b93-8a34-e5d7-18b5-0f7607221ad3@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-Originating-IP: [37.59.142.101] X-ClientProxiedBy: DAG3EX2.mxp6.local (172.16.2.22) To DAG3EX2.mxp6.local (172.16.2.22) X-Ovh-Tracer-GUID: 0ec3ce49-3f07-4883-a442-b551ec7df18e X-Ovh-Tracer-Id: 16659659450585452335 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedruddvtddguddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefvfhfhuffkffggjggtgfhisehtkeertddttdejnecuhfhrohhmpeforgigihhmvgcugghilhhlrghrugcuoehmrgigsehmtddtnhgsshgurdhnvghtqeenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnheirdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepmhgrgiesmhdttdhnsghsugdrnhgvthdprhgtphhtthhopehpsghonhiiihhnihesrhgvughhrghtrdgtohhm Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 79.137.123.220 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, ehabkost@redhat.com, slp@redhat.com, qemu-devel@nongnu.org, jmcneill@invisible.ca, Kamil Rytarowski , philmd@redhat.com, rth Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Le 10/03/2020 =C3=A0 11:58, Paolo Bonzini a =C3=A9crit=C2=A0: > On 10/03/20 07:45, Maxime Villard wrote: >>> It reproduces the existing logic found in whpx-all.c, and if there is >>> >> >> It's buggy there too and it has to be fixed in the hypervisor so it >> can't be done at the same time I'm both. KVM does it right by having >> a flag ("immediate_exit") that is set by the signal handler and >> checked by the hypervisor. >=20 > For what it's worth, WHPX's whpx_kick_vcpu invokes a "cancel entry" API > that is probably similar to what KVM does, so there's nothing to do the= re. >=20 > Paolo Having had some time to look at the actual code today, I'm wondering why WHPX uses whpx_vcpu_kick(), and why I even use qemu_cpu_kick_self() in NVMM. whpx_vcpu_kick() cancels the RunVirtualProcessor on the given VCPU. But that VCPU is not executing anyway, since we're the calling thread, and if we are in userland then we cannot be in the guest. It seems to me the cod= e should just break the loop directly instead of doing a self-kick, given that it is known that the VCPU is not executing. Maybe, whpx_vcpu_kick() causes a WHvRunVpExitReasonCanceled in the WHvRunVirtualProcessor() call that follows, which in turn causes "ret=3D1= " to leave the loop. That is, maybe the next WHvRunVirtualProcessor() acks the cancellation and leaves without doing anything, even if the cancellation was received when this function wasn't executing. So there i= s no bad effect, given that we still end up leaving the loop, which is the desired functional behavior. Looking at NVMM now, it seems to me there is the same thing. We do a self-kick but we're the calling thread and know the VCPU isn't executing. As a result of the self-kick the IPI handler sets qcpu->stop =3D true; And in the next iteration of the loop, we break because this bool is set. Again, we took a difficult path, but this is the desired final behavior. In both WHPX and NVMM, it seems that we are doing unnecessary self-kicks, and could just break the loop right away. What am I getting wrong? The thread logic in Qemu is not really easy to grasp.. Thanks, Maxime