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=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 B736EC433B4 for ; Tue, 11 May 2021 22:51:35 +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 6C113611F1 for ; Tue, 11 May 2021 22:51:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C113611F1 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.126064.237294 (Exim 4.92) (envelope-from ) id 1lgbDl-00061e-It; Tue, 11 May 2021 22:51:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 126064.237294; Tue, 11 May 2021 22:51:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lgbDl-00061X-G3; Tue, 11 May 2021 22:51:21 +0000 Received: by outflank-mailman (input) for mailman id 126064; Tue, 11 May 2021 22:51:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lgbDj-00061N-VV for xen-devel@lists.xenproject.org; Tue, 11 May 2021 22:51:19 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 48513bfd-42bc-48c1-875f-483a0cd01633; Tue, 11 May 2021 22:51:19 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 63CEE611F1; Tue, 11 May 2021 22:51:18 +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: 48513bfd-42bc-48c1-875f-483a0cd01633 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620773478; bh=3txn367DopLUmPkzGdSQyo882YvI9IA72Po80b+03HY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=P8y1HlNqgOVTRN3PszZBya/OkwRPpus6Hno2fjq+mhS90I9S4TgM8bI0+RlJaLGzB 3OpPkAQmXJc55Ykz457GymFRYdYQGnfkb9/zyg206NMcqcujUJHlbCFBYWsaAA98+N 7GCaausz7dBGipk/XoPAJ6K6BhMRDy4JGR8T8vvfnpNydZASRqGO7YTHOudMp5gc+5 DUvjxev9Uqp6j0xT2wV2MPBRil6wcLzNkoS8OENruSqYlZ6zc5fuYb2vBGBLO0tOzR 4XfbNJ/hSoP+SbiZJRInoiMG18cC/9LkQjm0d/v6U52xs17SPepYZueigLce8VWF1p f4dyU86kp66nA== Date: Tue, 11 May 2021 15:51:17 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall cc: xen-devel@lists.xenproject.org, Wei.Chen@arm.com, Henry.Wang@arm.com, Penny.Zheng@arm.com, Bertrand.Marquis@arm.com, Julien Grall , Stefano Stabellini , Volodymyr Babchuk Subject: Re: [PATCH RFCv2 05/15] xen/arm: mm: Avoid flushing the TLBs when mapping are inserted In-Reply-To: <20210425201318.15447-6-julien@xen.org> Message-ID: References: <20210425201318.15447-1-julien@xen.org> <20210425201318.15447-6-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Sun, 25 Apr 2021, Julien Grall wrote: > From: Julien Grall > > Currently, the function xen_pt_update() will flush the TLBs even when > the mappings are inserted. This is a bit wasteful because we don't > allow mapping replacement. Even if we were, the flush would need to > happen earlier because mapping replacement should use Break-Before-Make > when updating the entry. > > A single call to xen_pt_update() can perform a single action. IOW, it > is not possible to, for instance, mix inserting and removing mappings. > Therefore, we can use `flags` to determine what action is performed. > > This change will be particularly help to limit the impact of switching > boot time mapping to use xen_pt_update(). > > Signed-off-by: Julien Grall Nice improvement! Reviewed-by: Stefano Stabellini > --- > > Changes in v2: > - New patch > --- > xen/arch/arm/mm.c | 17 ++++++++++++++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 8ebb36899314..1fe52b3af722 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -1101,7 +1101,13 @@ static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int level, > /* We should be here with a valid MFN. */ > ASSERT(!mfn_eq(mfn, INVALID_MFN)); > > - /* We don't allow replacing any valid entry. */ > + /* > + * We don't allow replacing any valid entry. > + * > + * Note that the function xen_pt_update() relies on this > + * assumption and will skip the TLB flush. The function will need > + * to be updated if the check is relaxed. > + */ > if ( lpae_is_valid(entry) ) > { > if ( lpae_is_mapping(entry, level) ) > @@ -1333,11 +1339,16 @@ static int xen_pt_update(unsigned long virt, > } > > /* > - * Flush the TLBs even in case of failure because we may have > + * The TLBs flush can be safely skipped when a mapping is inserted > + * as we don't allow mapping replacement (see xen_pt_check_entry()). > + * > + * For all the other cases, the TLBs will be flushed unconditionally > + * even if the mapping are failed. This is because we may have > * partially modified the PT. This will prevent any unexpected > * behavior afterwards. > */ > - flush_xen_tlb_range_va(virt, PAGE_SIZE * nr_mfns); > + if ( !(flags & _PAGE_PRESENT) || mfn_eq(mfn, INVALID_MFN) ) > + flush_xen_tlb_range_va(virt, PAGE_SIZE * nr_mfns); > > spin_unlock(&xen_pt_lock); > > -- > 2.17.1 >