Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752357AbbHMJYi (ORCPT ); Thu, 13 Aug 2015 05:24:38 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:35489 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751869AbbHMJYg (ORCPT ); Thu, 13 Aug 2015 05:24:36 -0400 Date: Thu, 13 Aug 2015 10:24:32 +0100 From: Matt Fleming To: Ingo Molnar Cc: Thomas Gleixner , "H. Peter Anvin" , "Jonathan (Zhixiong) Zhang" , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Matt Fleming , Borislav Petkov , Ard Biesheuvel , Will Deacon , Catalin Marinas Subject: Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Message-ID: <20150813092432.GA2797@codeblueprint.co.uk> References: <1439396234-22863-1-git-send-email-matt@codeblueprint.co.uk> <1439396234-22863-3-git-send-email-matt@codeblueprint.co.uk> <20150813081917.GA14610@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150813081917.GA14610@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2276 Lines: 54 On Thu, 13 Aug, at 10:19:17AM, Ingo Molnar wrote: > > * Matt Fleming wrote: > > > From: "Jonathan (Zhixiong) Zhang" > > > > With ACPI APEI firmware first handling, generic hardware error > > record is updated by firmware in GHES memory region. On an arm64 > > platform, firmware updates GHES memory region with uncached > > access attribute, and then Linux reads stale data from cache. > > So this paragraph does not parse for me ... > > If it tries to explain a bug it falls very short of doing a proper job of that. I'll let Jonathan provide more details but I understood the problem to be a cache (in)coherency issue. The kernel currently maps the the GHES memory region as cacheable (PAGE_KERNEL) for all architectures. This memory region is used as a communication buffer for reporting hardware errors from the firmware to kernel. Essentially the firmware writes hardware error records there, trigger an NMI/interrupt, and the GHES driver goes off and grabs the error record from the GHES region. Since the firmware gets first crack at inspecting the error this mechanism is referred to as "firmware first" in the ACPI spec. Now, there's a mismatch on arm64 platforms between how the kernel maps the GHES region (PAGE_KERNEL) and how the firmware maps it (EFI_MEMORY_UC, i.e. uncacheable), leading to the possibility of the kernel GHES driver reading stale data from the cache when it receives the NMI/interrupt. As for exactly why the arm64 firmware uses an uncached mapping, I presume it's to avoid relying on the kernel to get the necessary cache flushing correct. The proposed solution is to query the EFI memory map to ensure the kernel uses a compatible mapping. None of this should affect x86, it still uses PAGE_KERNEL because we're yet to see any hardware that has an EFI memory map entry for the GHES region that's incompatible with PAGE_KERNEL. Jonathan, would you like to provide more details? -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/