From nobody Mon Apr 29 20:17:30 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail(p=none dis=none) header.from=linaro.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1529521813684338.04258363799204; Wed, 20 Jun 2018 12:10:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id E29FF211B7F89; Wed, 20 Jun 2018 12:10:12 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CF7D5211B7F87 for ; Wed, 20 Jun 2018 12:10:11 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id e18-v6so603327wrs.5 for ; Wed, 20 Jun 2018 12:10:11 -0700 (PDT) Received: from dogfood.home ([2a01:cb1d:112:6f00:dd7d:ecd4:eee5:21f4]) by smtp.gmail.com with ESMTPSA id b190-v6sm5217781wma.24.2018.06.20.12.10.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 12:10:09 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::244; helo=mail-wr0-x244.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=WFqLdwDHGo2toHSk8nPGdc94GfiC17thluwp99ptQls=; b=hS/Jo7tAylq72U6jyUGBoTFCYwlN9O9G+51uecxcxTAIo0cJ62qKrR7B5TofvOsOo9 8RYAP5LFfru1UsxXNDkqCmeBe3q4QNs3YeRAVHcr8N0STh+YcUjoxGakxF+7CDNsovEU SsS/AcT1+SzXCEE/Z4ZF4GKV5pdSzPIhfc8bo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=WFqLdwDHGo2toHSk8nPGdc94GfiC17thluwp99ptQls=; b=HCrhDFXrqi9RdJ0RPnDAMLkvhdmd+/InQtT6DXqgcgV/28QlcDh4Y/E9kUE48HA1Nx psd6xaYM7e09rKYcIVB1Ig/px20hi9/3ydT86HJU3i4RmQYsh+TxQM6WchiiRXx3S2o3 YiOhesZzumswhbZcHKut17sUhVOk8hhFPQF8bFd2i8HPzCUYg/oC77WhZi1AohWcbzoP fGVXAscQKu4pvy0JQvo7eMPcjXmA+VOywyWj5oUqjK8qt2VbGz65CYRRNISOsqFURC2o g8vjkijwZ41ygE1f7viLYip84g3y8ppdgx06Z0LjEbgIqKW5ysnHVgat0Zz0b//pl2t+ tkmQ== X-Gm-Message-State: APt69E0qKPBCak2ha/XfhhLXpCO1QDHsj0DccgRVwsMDRwzX+BLwSk/M ko+iIdMGLFoqVQ8/ZUTPMhabs0dp43w= X-Google-Smtp-Source: ADUXVKJ0R2qjBjM1VceDan/1l5Ws0UtXInXmcqRiBd5Xt4Fv7Hjzlu0PfNtk42M9a71yXtiSGmq7Kg== X-Received: by 2002:adf:b587:: with SMTP id c7-v6mr18927141wre.141.1529521810009; Wed, 20 Jun 2018 12:10:10 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org Date: Wed, 20 Jun 2018 21:10:07 +0200 Message-Id: <20180620191007.1250-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.17.1 Subject: [edk2] [PATCH] ArmPkg/ArmMmuLib ARM: remove cache maintenance of block mapping contents X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: leif.lindholm@linaro.org, Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Peculiarly enough, the current page table manipulation code takes it upon itself to write back and invalidate the memory contents covered by section mappings when their memory attributes change. It is not generally the case that data must be written back when such a change occurs, even when switching from cacheable to non-cacheable attributes, and in some cases, it is actually causing problems. (The cache maintenance is also performed on the PCIe MMIO regions as they get mapped by the PCI bus driver, and under virtualization, each cache maintenance operation on an emulated MMIO region triggers a round trip to the host and back) So let's just drop this code. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c b/ArmPkg/Library/= ArmMmuLib/Arm/ArmMmuLibCore.c index 9bf4ba03fd5b..d1bca4c601b8 100644 --- a/ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c +++ b/ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c @@ -718,12 +718,6 @@ UpdateSectionEntries ( if (CurrentDescriptor !=3D Descriptor) { Mva =3D (VOID *)(UINTN)(((UINTN)FirstLevelIdx + i) << TT_DESCRIPTO= R_SECTION_BASE_SHIFT); =20 - // Clean/invalidate the cache for this section, but only - // if we are modifying the memory type attributes - if (((CurrentDescriptor ^ Descriptor) & TT_DESCRIPTOR_SECTION_CACH= E_POLICY_MASK) !=3D 0) { - WriteBackInvalidateDataCacheRange (Mva, SIZE_1MB); - } - // Only need to update if we are changing the descriptor FirstLevelTable[FirstLevelIdx + i] =3D Descriptor; ArmUpdateTranslationTableEntry ((VOID *)&FirstLevelTable[FirstLeve= lIdx + i], Mva); --=20 2.17.1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel