From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751642AbbHGJua (ORCPT ); Fri, 7 Aug 2015 05:50:30 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:34234 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751078AbbHGJuR convert rfc822-to-8bit (ORCPT ); Fri, 7 Aug 2015 05:50:17 -0400 MIME-Version: 1.0 In-Reply-To: <20150807093750.GB2625@codeblueprint.co.uk> References: <1438868434-28736-1-git-send-email-zjzhang@codeaurora.org> <1438868434-28736-5-git-send-email-zjzhang@codeaurora.org> <20150807093750.GB2625@codeblueprint.co.uk> Date: Fri, 7 Aug 2015 11:50:16 +0200 Message-ID: Subject: Re: [PATCH V10 4/5] arm64: apei: implement arch_apei_get_mem_attributes() From: Ard Biesheuvel To: Matt Fleming Cc: "Jonathan (Zhixiong) Zhang" , Catalin Marinas , Will Deacon , Fu Wei , Al Stone , Borislav Petkov , Matt Fleming , "Rafael J. Wysocki" , Hanjun Guo , Leif Lindholm , "linux-kernel@vger.kernel.org" , Linaro ACPI Mailman List , Timur Tabi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7 August 2015 at 11:37, Matt Fleming wrote: > On Fri, 07 Aug, at 11:00:17AM, Ard Biesheuvel wrote: >> >> The EFI memory types are not exclusive, and so many regions will have >> all of the above set. The UEFI spec does not define how to interpret >> these superimposed attributes, it is up to the OS to decide on a >> consistent approach. >> >> For instance, this region (captured from a arm64 boot log with >> uefi_debug set on the command line) >> >> [Runtime Data |RUN| | | | |WB|WT|WC|UC] >> >> would be mapped uncached when following the above logic, while it >> makes more sense to map using PAGE_KERNEL in this case. > > Urgh... good point Ard. Right now this is limited to the GHES driver, so > it's unclear whether this patch is buggy in practice or not. > > Does it *ever* make sense to map a region as cacheable (WB/WT/WC) on > arm64 for the APEI/GHES case? Does the firmware handle the necessary > cache flushing? > No it does not. Currently, we only consider EFI_MEMORY_WB when discovering system RAM from the UEFI memory map, so the direct linear mapping should have a hole where the APEI/GHES regions lives if it doesn't have the WB attribute set. This means we can map it WT/WC/UC without violating architectural rules regarding mismatches attributes, but it requires an explicit ioremap() >> From the spec: >> >> """ >> EFI_MEMORY_UC: The memory region supports being configured as not cacheable. >> EFI_MEMORY_WC: The memory region supports being configured as write combining. >> EFI_MEMORY_WT: The memory region supports being configured as >> cacheable with a “write through” policy. Writes that hit in the cache >> will also be written to main memory. >> EFI_MEMORY_WB: The memory region supports being configured as >> cacheable with a “write back” policy. Reads and writes that hit in the >> cache do not propagate to main memory. Dirty data is written back to >> main memory when a new cache line is allocated. >> """ > > Jonathan, can you please provide the EFI memory map region attributes > for the GHES region that requires this series? > > -- > Matt Fleming, Intel Open Source Technology Center