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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3EC08C433DB for ; Tue, 23 Feb 2021 20:40:43 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 DD7B864DD3 for ; Tue, 23 Feb 2021 20:40:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD7B864DD3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.89091.167563 (Exim 4.92) (envelope-from ) id 1lEeTv-0000dB-3C; Tue, 23 Feb 2021 20:40:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 89091.167563; Tue, 23 Feb 2021 20:40:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lEeTv-0000d4-0D; Tue, 23 Feb 2021 20:40:31 +0000 Received: by outflank-mailman (input) for mailman id 89091; Tue, 23 Feb 2021 20:40:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lEeTt-0000cz-VK for xen-devel@lists.xenproject.org; Tue, 23 Feb 2021 20:40:29 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 878ec573-2ba2-4b0c-8bf7-c2d49312d6dd; Tue, 23 Feb 2021 20:40:29 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 2DFDC601FF; Tue, 23 Feb 2021 20:40:28 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 878ec573-2ba2-4b0c-8bf7-c2d49312d6dd DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614112828; bh=GQUobiaItm0t2cmOOoyfX4zeMrB5aEvhU2hMF0b1duk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=B0+Yysz1Lm1d2Kf1NfePaJhMx2Qej0kYt9qYL/HM9h1Ek9hOb1MlvnkusGMog7D/6 q63eCxlsRHCcHsIfMVyd3Heh8Q/jEmx9ZyTZyUeLb9H/4V9mh5avZVLvpVzPAil61S tNPv+iRfPVCwV8OOIj6IPBzju33q9meL+e3RhHGpyYnCrrriA5wg8P4X3mOnP5xaZ+ UsJBgZhl4c8nsc3SVoB0HoM9qYrneeOGtyb3M5HCBhFtjsXBPlqvcxluh0n9DC4J8/ dQg5FGE6m+SkIFdXb4AU2925HCvV6O26VJ+sRcTg0OlAFgxVr+e5o9s15cQOx4f2bt JUmgZSqYwHAsA== Date: Tue, 23 Feb 2021 12:40:27 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall cc: Stefano Stabellini , Bertrand Marquis , "xen-devel@lists.xenproject.org" , "iwj@xenproject.org" , Julien Grall , Volodymyr Babchuk , dfaggioli@suse.com, George.Dunlap@citrix.com Subject: Re: [PATCH for-4.15] xen/vgic: Implement write to ISPENDR in vGICv{2, 3} In-Reply-To: <767e2028-ca86-bd0f-e936-c386066c11c8@xen.org> Message-ID: References: <20210220140412.31610-1-julien@xen.org> <767e2028-ca86-bd0f-e936-c386066c11c8@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 23 Feb 2021, Julien Grall wrote: > Hi Stefano, > > On 23/02/2021 01:24, Stefano Stabellini wrote: > > On Mon, 22 Feb 2021, Bertrand Marquis wrote: > > > > On 20 Feb 2021, at 14:04, Julien Grall wrote: > > The consequence of this patch is that a guest can cause vcpu_unblock(v), > > hence vcpu_wake(v), to be called for its own vcpu, which basically > > always changes v to RUNSTATE_runnable. However, that alone shouldn't > > allow v to always come up ahead of any other vcpus in the queue, right? > > It should be safe. I just wanted a second opinion on this :-) > > vcpu_wake() only tells the scheduler that the vCPU can be run, it is then up > to the scheduler to decide what to do. AFAIU, for credit{1, 2}, each vCPU will > have some credit. If you run out of credit, then you vCPU will not be > descheduled if there is work do it. OK, great, it matches my understanding. Thanks for checking. Reviewed-by: Stefano Stabellini