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:c0c::241; helo=mail-wr0-x241.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 E62DD210D852C for ; Thu, 21 Jun 2018 03:48:26 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id k6-v6so2675817wrp.4 for ; Thu, 21 Jun 2018 03:48:26 -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=/5qpnytE85KuQtF38pzVFP15h0Ej/dKNjPTKTjgPYv4=; b=bP5dv2RQ8ZBOCfJo8ObY3TwxfmWTU+lI9lYjjtgzE08nVmCv91eonob1dDiyoGDPg4 p72pUATgCAJQctR5aL8Q9S4MYVsmEykIZctgxrAnB/yhpxhOFtRIm1DXtWwmCRO3zTVH cKuq4W6nzxHrLCSHC1A1izsapNUk8r4QwfeNk= 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=/5qpnytE85KuQtF38pzVFP15h0Ej/dKNjPTKTjgPYv4=; b=XJrA9RmzUQWzzvBE5XTUFT6lVF9vd990C4oOn5oK92ZtnWvq+HFhuqVeSn8M8ZSvHI glyCpFaV5fExKzhQcIvxySxFJB9jvkZ2WF7GXhw5uMq6LYeU9MxaqGFdchHyI0VWyY7l 9wagwQgoFVhIUyUtKDVn8b3o4XYemPOaaPMdTlrYdI3tSWMUXyFoVpxWRxFxcpz+RIK7 WEpZrp6114sunwwPtmfG7N3cLljPzKXKHW6cLqisDaUyaCBjzi1pEZXF015GM9Rwz5z9 IiF4dydv+5Hv30Mxt/to93+TfprMukl9F7Vaw3qmy5+TDJjvYva8ceHWzlHVB/QN5GyZ OkLg== X-Gm-Message-State: APt69E0dGJVGztoRfipQCs2EmGrAXnTfd5zdI/7mBpox9CztAXZBykUO o69oGIc0WuV7d4x1vUlMNQPRaQ== X-Google-Smtp-Source: ADUXVKJDDeFRP4Jp3t6H/wU5MmHyyHv6wfMm62DiJu0uAr/dEtRAgQe+aFO+qcUrgXmzEUOgOigBQg== X-Received: by 2002:adf:f7cf:: with SMTP id a15-v6mr20934066wrq.108.1529578104584; Thu, 21 Jun 2018 03:48:24 -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 z14-v6sm4386056wrm.49.2018.06.21.03.48.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Jun 2018 03:48:23 -0700 (PDT) Date: Thu, 21 Jun 2018 11:48:21 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Chris Co Message-ID: <20180621104821.gq3stweaokjmpre3@bivouac.eciton.net> References: <20180620191007.1250-1-ard.biesheuvel@linaro.org> <20180620220559.2g5wvickl6bgtnzi@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: 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: Thu, 21 Jun 2018 10:48:27 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Replying to this one rather than the new patches, to keep the thread going. On Thu, Jun 21, 2018 at 08:21:22AM +0200, Ard Biesheuvel wrote: > On 21 June 2018 at 00:05, Leif Lindholm wrote: > > 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. > > No, this one is different. This does not flush the page containing the > page table entry that is modified, but it flushes the memory that the > page table entry maps (a 1 MB section in this case) *scratches head* Sounds like someone was trying to be overly helpful by completely hiding architectural complexity. Surely if someone is remapping a region to different cacheability settings, the responsibility needs to be on them to manually clean/invalidate? So yeah, that needs to go. > > But if so, don't we also want to get rid of the other two instances of > > WriteBackInvalidateDataCacheRange() in this file? > > If we assume page table walks are coherent, then yes, we could remove > some more code, but that should be a separate patch. Hmm... I'm starting to have second thoughts about that. UEFI explicitly says "The binding does not mandate whether page tables are cached or un-cached.". Otoh, we know that we only practically support implementations that are required to be able to do coherent page table walks. So maybe we can nuke it and reinstate it under a Pcd (default off) if anyone screams? / 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 > >>