From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::244; helo=mail-wm0-x244.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 45046211BFCCA for ; Wed, 20 Jun 2018 15:06:04 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id x6-v6so1863021wmc.3 for ; Wed, 20 Jun 2018 15:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=75MlvPhMGpUadqSsA1KEuP9kyFFzyUFov3/HGN+BWw4=; b=VTM9jhOAfl+Xi72ChwysZMkqYHpbiKopHe+eYluwNpBQsFKAhfLhuk3e4e06w1PLuF YyEDfZP7uvGAfMiBeDM+YttcOkTfG1WhZsBh2zojKLoJ8Yr9Q83f2K0epS4CPDLx3K5L HB5ccqTKDU3WIdivGSxCLOYgWxV3NtGhomio8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=75MlvPhMGpUadqSsA1KEuP9kyFFzyUFov3/HGN+BWw4=; b=tARo2maRrRmd0vMZaPPRWAdk0vlbsbXBYTIHUivnBychLMKL3OGXBo6Ny1koOaW4IQ EX6ORRNgr09ObvLa+t4KSTUWbVGKfCOswfl0VudF19m2GaWKHV4lKhOpFyaDVPqs2nqd 2mJdsj7qsY67ELqRG6gGuWYsRI94svogpWOzaNS5f+E9vAaOlC/XYyBbhFunBG89GQX+ Mr/Ahj6bOgvt1kpiipHs2coLN7G/b4I32zRUkoCce2YPeqZkjjueQ3M5R02tDmAb6DrK 7vBTDaCueUoS+Dp37h2E5Rs1/Dud4ggu7Xd1M1Ae080kF2ApmnfAiV6Yx6gv0Cz8DGaB 1Yww== X-Gm-Message-State: APt69E0rneNWCPER5aKnjd6Y3lgFJTtWMq8y+afQrHdkKfl/RwP0ZrD5 69N029kmnNB2RnjY2eCYrCWaxw== X-Google-Smtp-Source: ADUXVKL0nrv8r80Ow7Yh61Ha+ns7nsDKcr6YpAqPwZkgsbd6FmoXmnbPmjr+xOnP7K4m8Tpug/T4yA== X-Received: by 2002:a1c:ee06:: with SMTP id m6-v6mr3170267wmh.70.1529532362089; Wed, 20 Jun 2018 15:06:02 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id 84-v6sm4097971wme.16.2018.06.20.15.06.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Jun 2018 15:06:00 -0700 (PDT) Date: Wed, 20 Jun 2018 23:05:59 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, Christopher.Co@microsoft.com Message-ID: <20180620220559.2g5wvickl6bgtnzi@bivouac.eciton.net> References: <20180620191007.1250-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20180620191007.1250-1-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [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: , X-List-Received-Date: Wed, 20 Jun 2018 22:06:04 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 20, 2018 at 09:10:07PM +0200, Ard Biesheuvel wrote: > 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. I guess this is a remnant from pre-ARMv7 days, when translation table walks weren't inner-cacheable. I think we've already determined that ARMv7-A+ is required for PI compliance anyway, so I guess dropping this should be fine. But if so, don't we also want to get rid of the other two instances of WriteBackInvalidateDataCacheRange() in this file? / Leif > 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 != Descriptor) { > Mva = (VOID *)(UINTN)(((UINTN)FirstLevelIdx + i) << TT_DESCRIPTOR_SECTION_BASE_SHIFT); > > - // Clean/invalidate the cache for this section, but only > - // if we are modifying the memory type attributes > - if (((CurrentDescriptor ^ Descriptor) & TT_DESCRIPTOR_SECTION_CACHE_POLICY_MASK) != 0) { > - WriteBackInvalidateDataCacheRange (Mva, SIZE_1MB); > - } > - > // Only need to update if we are changing the descriptor > FirstLevelTable[FirstLevelIdx + i] = Descriptor; > ArmUpdateTranslationTableEntry ((VOID *)&FirstLevelTable[FirstLevelIdx + i], Mva); > -- > 2.17.1 >