From patchwork Mon Jun 19 17:01:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 13284837 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0FB37EB64D9 for ; Mon, 19 Jun 2023 17:01:39 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.551247.860730 (Exim 4.92) (envelope-from ) id 1qBIFs-0004mZ-Rn; Mon, 19 Jun 2023 17:01:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 551247.860730; Mon, 19 Jun 2023 17:01:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qBIFs-0004mO-OS; Mon, 19 Jun 2023 17:01:28 +0000 Received: by outflank-mailman (input) for mailman id 551247; Mon, 19 Jun 2023 17:01:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qBIFq-0004Y6-U7 for xen-devel@lists.xenproject.org; Mon, 19 Jun 2023 17:01:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qBIFq-0002fP-K2; Mon, 19 Jun 2023 17:01:26 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1qBIFq-00079R-Ci; Mon, 19 Jun 2023 17:01:26 +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:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=Z5DRZNZmlBW9wLWM72auv5rCsE+gqkJPzk13KavQHZY=; b=hQHBgzPEL0IUqiiOdL9ZuROF+w e7n3xPToVnbSWxPv6sFGuKZ+s2VRKe6FV4sUneSINgB41LKNdnLdvMCDEHUOklzonZfgp6qYRsD4W yaVwyHS/OLAxjTd0Rf8OEUzA+GKkLFfZ55t3wbdENLRKVh2Fu6pPsCfElVwHCWyghOdo=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, michal.orzel@amd.com, Henry.Wang@arm.com, Julien Grall , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH 6/7] xen/arm: mm: Add missing ISB in xen_pt_update() Date: Mon, 19 Jun 2023 18:01:14 +0100 Message-Id: <20230619170115.81398-7-julien@xen.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230619170115.81398-1-julien@xen.org> References: <20230619170115.81398-1-julien@xen.org> MIME-Version: 1.0 From: Julien Grall Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12): "The DMB and DSB memory barriers affect reads and writes to the memory system generated by load/store instructions and data or unified cache maintenance operations being executed by the processor. Instruction fetches or accesses caused by a hardware translation table access are not explicit accesses." Note that second sentence is not part of the newer Armv8 spec. But the interpretation is not much different. The updated entry will not be used until xen_pt_update() completes. So rather than adding the ISB after write_pte() in create_xen_table() and xen_pt-update_entry(), add it in xen_pt_update(). Also document the reasoning of the deferral after each write_pte() calls. Fixes: 07d11f63d03e ("xen/arm: mm: Avoid flushing the TLBs when mapping are inserted") Signed-off-by: Julien Grall Reviewed-by: Henry Wang Tested-by: Henry Wang Reviewed-by: Bertrand Marquis --- xen/arch/arm/mm.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index e460249736c3..84e652799dd2 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -779,6 +779,11 @@ static int create_xen_table(lpae_t *entry) pte = mfn_to_xen_entry(mfn, MT_NORMAL); pte.pt.table = 1; write_pte(entry, pte); + /* + * No ISB here. It is deferred to xen_pt_update() as the new table + * will not be used for hardware translation table access as part of + * the mapping update. + */ return 0; } @@ -1017,6 +1022,10 @@ static int xen_pt_update_entry(mfn_t root, unsigned long virt, } write_pte(entry, pte); + /* + * No ISB or TLB flush here. They are deferred to xen_pt_update() + * as the entry will not be used as part of the mapping update. + */ rc = 0; @@ -1196,6 +1205,9 @@ static int xen_pt_update(unsigned long virt, /* * The TLBs flush can be safely skipped when a mapping is inserted * as we don't allow mapping replacement (see xen_pt_check_entry()). + * Although we still need an ISB to ensure any DSB in + * write_pte() will complete because the mapping may be used soon + * after. * * For all the other cases, the TLBs will be flushed unconditionally * even if the mapping has failed. This is because we may have @@ -1204,6 +1216,8 @@ static int xen_pt_update(unsigned long virt, */ if ( !((flags & _PAGE_PRESENT) && !mfn_eq(mfn, INVALID_MFN)) ) flush_xen_tlb_range_va(virt, PAGE_SIZE * nr_mfns); + else + isb(); spin_unlock(&xen_pt_lock);