Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932619AbbFLXob (ORCPT ); Fri, 12 Jun 2015 19:44:31 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:59177 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932272AbbFLXo2 (ORCPT ); Fri, 12 Jun 2015 19:44:28 -0400 Message-ID: <557B6ED9.3020706@codeaurora.org> Date: Fri, 12 Jun 2015 16:44:25 -0700 From: "Zhang, Jonathan Zhixiong" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Borislav Petkov CC: Matt Fleming , Thomas Gleixner , fu.wei@linaro.org, al.stone@linaro.org, tony.luck@gmail.com, rjw@rjwysocki.net, lenb@kernel.org, ying.huang@intel.com, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory References: <1434047160-23358-1-git-send-email-zjzhang@codeaurora.org> <1434047160-23358-5-git-send-email-zjzhang@codeaurora.org> <20150612162924.GH9084@pd.tnic> In-Reply-To: <20150612162924.GH9084@pd.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3352 Lines: 88 On 6/12/2015 9:29 AM, Borislav Petkov wrote: > On Thu, Jun 11, 2015 at 11:26:00AM -0700, Jonathan (Zhixiong) Zhang wrote: >> From: "Jonathan (Zhixiong) Zhang" >> >> With ACPI APEI firmware first handling, generic hardware error >> record is updated by firmware in GHES memory region. When firmware >> updated GHES memory region with uncached access attribute, Linux >> reads stale data from cache. >> >> GHES memory region should be mapped with cache attributes >> according to EFI memory map when applicable. On such system, if >> firmware updates RAM directly without going through cache, >> EFI memory map has GHES memory region defined as uncached; >> If firmware updates cache, EFI memory map has GHES memory region >> defined as cached. >> >> On EFI system, if GHES memory region has EFI_MEMORY_UC attribute >> defined, map the page with arch defined UC page protection type. >> >> Signed-off-by: Jonathan (Zhixiong) Zhang >> --- >> drivers/acpi/apei/ghes.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >> index e82d0976a5d0..5cfd951ebf67 100644 >> --- a/drivers/acpi/apei/ghes.c >> +++ b/drivers/acpi/apei/ghes.c >> @@ -48,6 +48,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include >> @@ -164,8 +165,14 @@ static void __iomem *ghes_ioremap_pfn_irq(u64 pfn) >> unsigned long vaddr; >> >> vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr); >> - ioremap_page_range(vaddr, vaddr + PAGE_SIZE, >> + >> + if (efi_mem_attributes(pfn << PAGE_SHIFT) & EFI_MEMORY_UC) { >> + ioremap_page_range(vaddr, vaddr + PAGE_SIZE, >> + pfn << PAGE_SHIFT, ARCH_APEI_PAGE_KERNEL_UC); >> + } else { >> + ioremap_page_range(vaddr, vaddr + PAGE_SIZE, >> pfn << PAGE_SHIFT, PAGE_KERNEL); >> + } >> >> return (void __iomem *)vaddr; > > This is still hacky. All of a sudden, ghes code gets to know about EFI > which looks like a mishmash to me. > > Maybe it would be cleaner if you added an arch-specific > > arch_get_mem_attribute(phys_addr); > > which returns a pgprot_t thing which you can use directly above, like > so: > > ioremap_page_range(vaddr, > vaddr + PAGE_SIZE, > pfn << PAGE_SHIFT, > arch_get_mem_attribute(pfn << PAGE_SHIFT)); > > Each arch can then return what it likes with arch_get_mem_attribute(). > Thanks for the review, Borislav. I will do that. Since such function is only needed for APEI functionality, at least as of today, I will name it arch_apei_get_mem_attribute(). I will add implementations for arm64 and x86 since those are the only archs having HAVE_ACPI_APEI defined in Kconfig. The upstream kernel today does not have HAVE_ACPI_APEI defined for arm64, but it needs to be and will be. -- Jonathan (Zhixiong) Zhang The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/