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=-7.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 EDA34C433E0 for ; Tue, 2 Feb 2021 15:24:32 +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 92C9064F54 for ; Tue, 2 Feb 2021 15:24:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92C9064F54 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.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.80600.147496 (Exim 4.92) (envelope-from ) id 1l6xXB-0001nP-Jc; Tue, 02 Feb 2021 15:24:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 80600.147496; Tue, 02 Feb 2021 15:24:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l6xXB-0001nI-Er; Tue, 02 Feb 2021 15:24:05 +0000 Received: by outflank-mailman (input) for mailman id 80600; Tue, 02 Feb 2021 15:24:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l6xX9-0001n6-El for xen-devel@lists.xenproject.org; Tue, 02 Feb 2021 15:24:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l6xX7-0007yS-Om; Tue, 02 Feb 2021 15:24:01 +0000 Received: from 54-240-197-239.amazon.com ([54.240.197.239] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l6xX7-0000Nz-Iw; Tue, 02 Feb 2021 15:24:01 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Cc:From:References:To:Subject; bh=Mw4IMl4Ae0U2lXSykBhjVy2sBzxa2prqjIT4wRg2xAs=; b=CDkCecAwn9Pr/GmDSvoGCjaRS6 WPI4tCp3w/VXG98KwumOkznD1GDNqmYntXBjURUesUn/UnviHtsyQxJA3x7+IoKohhJtqMjPwBYlc 8kqSxErqK5Gju/DX8nOhUsHJop6OLCQLnDvc3aUj2sd6jC8a2xSQ0z8EPkPSGdZ8rKvs=; Subject: Re: Null scheduler and vwfi native problem To: Dario Faggioli , =?UTF-8?Q?Anders_T=c3=b6rnqvist?= , xen-devel@lists.xenproject.org, Stefano Stabellini References: <207305e4e2998614767fdcc5ad83ced6de982820.camel@suse.com> <744ddde6-a228-82fc-76b9-401926d7963b@xen.org> <18ef4619-19ae-90d2-459c-9b5282b49176@codiax.se> <4760cbac-b006-78bc-b064-3265384f6707@xen.org> <311bb201bcacfd356f0c0b67856754eceae39e37.camel@suse.com> From: Julien Grall Cc: Jan Beulich , Andrew Cooper , Juergen Gross Message-ID: <7f2ec84a-9814-ffb1-0940-e936a80afbbb@xen.org> Date: Tue, 2 Feb 2021 15:23:59 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <311bb201bcacfd356f0c0b67856754eceae39e37.camel@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit (Adding Andrew, Jan, Juergen for visibility) Hi Dario, On 02/02/2021 15:03, Dario Faggioli wrote: > On Tue, 2021-02-02 at 07:59 +0000, Julien Grall wrote: >> Hi Dario, >> >> I have had a quick look at your place. The RCU call in >> leave_hypervisor_to_guest() needs to be placed just after the last >> call >> to check_for_pcpu_work(). >> >> Otherwise, you may be preempted and keep the RCU quiet. >> > Ok, makes sense. I'll move it. > >> The placement in enter_hypervisor_from_guest() doesn't matter too >> much, >> although I would consider to call it as a late as possible. >> > Mmmm... Can I ask why? In fact, I would have said "as soon as > possible". Because those functions only access data for the current vCPU/domain. This is already protected by the fact that the domain is running. By leaving the "quiesce" mode later, you give an opportunity to the RCU to release memory earlier. In reality, it is probably still too early as a pCPU can be considered quiesced until a call to rcu_lock*() (such rcu_lock_domain()). But this would require some investigation to check if we effectively protect all the region with the RCU helpers. This is likely too complicated for 4.15. Cheers, -- Julien Grall