From: "Jonathan (Zhixiong) Zhang" <[email protected]>
Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
memory types to MAIR attribute encodings for arm64.
If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
type according to the UEFI spec. Otherwise, return PAGE_KERNEL.
Reviewed-by: Catalin Marinas <[email protected]>
Acked-by: Hanjun Guo <[email protected]>
Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Will Deacon <[email protected]>
---
V2: Changed arm64's implementation of arch_apei_get_mem_attributes()
from inline function to out of line function, based on Ingo's
feedback.
arch/arm64/include/asm/acpi.h | 5 +++++
arch/arm64/kernel/acpi.c | 29 +++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 406485ed110a..8084f3640006 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -92,4 +92,9 @@ static inline const char *acpi_get_enable_method(int cpu)
{
return acpi_psci_present() ? "psci" : NULL;
}
+
+#ifdef CONFIG_ACPI_APEI
+pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+#endif
+
#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 19de7537e7d3..9f083606e5bf 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -29,6 +29,11 @@
#include <asm/cpu_ops.h>
#include <asm/smp_plat.h>
+#ifdef CONFIG_ACPI_APEI
+#include <linux/efi.h>
+#include <asm/pgtable.h>
+#endif
+
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -230,3 +235,27 @@ void __init acpi_gic_init(void)
early_acpi_os_unmap_memory((char *)table, tbl_size);
}
+
+#ifdef CONFIG_ACPI_APEI
+pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ /*
+ * According to "Table 8 Map: EFI memory types to AArch64 memory
+ * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
+ * mapped to a corresponding MAIR attribute encoding.
+ * The EFI memory attribute advises all possible capabilities
+ * of a memory region. We use the most efficient capability.
+ */
+
+ u64 attr;
+
+ attr = efi_mem_attributes(addr);
+ if (attr & EFI_MEMORY_WB)
+ return PAGE_KERNEL;
+ if (attr & EFI_MEMORY_WT)
+ return __pgprot(PROT_NORMAL_WT);
+ if (attr & EFI_MEMORY_WC)
+ return __pgprot(PROT_NORMAL_NC);
+ return __pgprot(PROT_DEVICE_nGnRnE);
+}
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
From: "Jonathan (Zhixiong) Zhang" <[email protected]>
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.
With current code, GHES memory region is mapped with PAGE_KERNEL
based on the assumption that cache coherency of GHES memory region
is maintained by firmware on all platforms. This assumption is
not true for above mentioned arm64 platform.
Instead GHES memory region should be mapped with page protection type
according to what is returned from arch_apei_get_mem_attribute().
Acked-by: Borislav Petkov <[email protected]>
Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
---
drivers/acpi/apei/ghes.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 23981ac1c6c2..f742335bd8bb 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -160,8 +160,10 @@ 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,
- pfn << PAGE_SHIFT, PAGE_KERNEL);
+ ioremap_page_range(vaddr,
+ vaddr + PAGE_SIZE,
+ pfn << PAGE_SHIFT,
+ arch_apei_get_mem_attribute(pfn << PAGE_SHIFT));
return (void __iomem *)vaddr;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Fri, 14 Aug, at 03:37:29PM, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>
> Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
> memory types to MAIR attribute encodings for arm64.
>
> If the physical address has memory attributes defined by EFI
> memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
> type according to the UEFI spec. Otherwise, return PAGE_KERNEL.
>
> Reviewed-by: Catalin Marinas <[email protected]>
> Acked-by: Hanjun Guo <[email protected]>
> Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Hanjun Guo <[email protected]>
> Cc: Will Deacon <[email protected]>
> ---
> V2: Changed arm64's implementation of arch_apei_get_mem_attributes()
> from inline function to out of line function, based on Ingo's
> feedback.
>
> arch/arm64/include/asm/acpi.h | 5 +++++
> arch/arm64/kernel/acpi.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
Looks fine to me, though it appears to be missing Ard's Reviewed-by
tag (the only change from the previous version is that it's no longer
inline).
Reviewed-by: Matt Fleming <[email protected]>
Ingo, are you going to pick up this patch series and apply it directly
to tip if you're OK with this version?
--
Matt Fleming, Intel Open Source Technology Center
On Fri, 14 Aug, at 03:37:30PM, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>
> 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.
>
> With current code, GHES memory region is mapped with PAGE_KERNEL
> based on the assumption that cache coherency of GHES memory region
> is maintained by firmware on all platforms. This assumption is
> not true for above mentioned arm64 platform.
>
> Instead GHES memory region should be mapped with page protection type
> according to what is returned from arch_apei_get_mem_attribute().
>
> Acked-by: Borislav Petkov <[email protected]>
> Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
> ---
> drivers/acpi/apei/ghes.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 23981ac1c6c2..f742335bd8bb 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -160,8 +160,10 @@ 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,
> - pfn << PAGE_SHIFT, PAGE_KERNEL);
> + ioremap_page_range(vaddr,
> + vaddr + PAGE_SIZE,
> + pfn << PAGE_SHIFT,
> + arch_apei_get_mem_attribute(pfn << PAGE_SHIFT));
>
> return (void __iomem *)vaddr;
> }
Y'know, this would be more readable if written as,
unsigned long vaddr, paddr;
pgprot_t prot;
vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
paddr = pfn << PAGE_SHIFT;
prot = arch_apei_get_mem_attribute(paddr);
ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
But either way,
Reviewed-by: Matt Fleming <[email protected]>
--
Matt Fleming, Intel Open Source Technology Center
On 8/17/2015 6:05 AM, Matt Fleming wrote:
> On Fri, 14 Aug, at 03:37:29PM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>>
>> Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
>> memory types to MAIR attribute encodings for arm64.
>>
>> If the physical address has memory attributes defined by EFI
>> memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
>> type according to the UEFI spec. Otherwise, return PAGE_KERNEL.
>>
>> Reviewed-by: Catalin Marinas <[email protected]>
>> Acked-by: Hanjun Guo <[email protected]>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
>> Cc: Ingo Molnar <[email protected]>
>> Cc: Matt Fleming <[email protected]>
>> Cc: Hanjun Guo <[email protected]>
>> Cc: Will Deacon <[email protected]>
>> ---
>> V2: Changed arm64's implementation of arch_apei_get_mem_attributes()
>> from inline function to out of line function, based on Ingo's
>> feedback.
>>
>> arch/arm64/include/asm/acpi.h | 5 +++++
>> arch/arm64/kernel/acpi.c | 29 +++++++++++++++++++++++++++++
>> 2 files changed, 34 insertions(+)
>>
>
> Looks fine to me, though it appears to be missing Ard's Reviewed-by
> tag (the only change from the previous version is that it's no longer
> inline).
>
> Reviewed-by: Matt Fleming <[email protected]>
Thanks. Will add both Reviewed-by.
>
> Ingo, are you going to pick up this patch series and apply it directly
> to tip if you're OK with this version?
>
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On 8/17/2015 6:13 AM, Matt Fleming wrote:
> On Fri, 14 Aug, at 03:37:30PM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>>
>> 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.
>>
>> With current code, GHES memory region is mapped with PAGE_KERNEL
>> based on the assumption that cache coherency of GHES memory region
>> is maintained by firmware on all platforms. This assumption is
>> not true for above mentioned arm64 platform.
>>
>> Instead GHES memory region should be mapped with page protection type
>> according to what is returned from arch_apei_get_mem_attribute().
>>
>> Acked-by: Borislav Petkov <[email protected]>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <[email protected]>
>> ---
>> drivers/acpi/apei/ghes.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 23981ac1c6c2..f742335bd8bb 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -160,8 +160,10 @@ 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,
>> - pfn << PAGE_SHIFT, PAGE_KERNEL);
>> + ioremap_page_range(vaddr,
>> + vaddr + PAGE_SIZE,
>> + pfn << PAGE_SHIFT,
>> + arch_apei_get_mem_attribute(pfn << PAGE_SHIFT));
>>
>> return (void __iomem *)vaddr;
>> }
>
> Y'know, this would be more readable if written as,
>
> unsigned long vaddr, paddr;
> pgprot_t prot;
>
> vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
>
> paddr = pfn << PAGE_SHIFT;
> prot = arch_apei_get_mem_attribute(paddr);
>
> ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
>
> But either way,
>
> Reviewed-by: Matt Fleming <[email protected]>
Thanks. I will go with the easier to read way.
>
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
* Jonathan (Zhixiong) Zhang <[email protected]> wrote:
> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>
> 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.
This paragraph *still* doesn't parse for me. It's not any English
I can recognize: what is a 'With ACPI APEI firmware first handling'?
> With current code, GHES memory region is mapped with PAGE_KERNEL
> based on the assumption that cache coherency of GHES memory region
> is maintained by firmware on all platforms. This assumption is
> not true for above mentioned arm64 platform.
>
> Instead GHES memory region should be mapped with page protection type
> according to what is returned from arch_apei_get_mem_attribute().
... plus what this changelog still doesn't mention is the most important part of
any bug fix description: how does the user notice this in practice and why does he
care?
Thanks,
Ingo
On 8/22/2015 2:24 AM, Ingo Molnar wrote:
>
> * Jonathan (Zhixiong) Zhang <[email protected]> wrote:
>
>> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>>
>> 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.
>
> This paragraph *still* doesn't parse for me. It's not any English
> I can recognize: what is a 'With ACPI APEI firmware first handling'?
APEI is ACPI Platform Error Interface; it is part of ACPI spec,
defining the aspect of hardware error handling. "firmware first
handling" is a terminology used in APEI. It describes such mechanism
that when hardware error happens, firmware intersects/handles such
hardware error, formulates hardware error record and writes the record
to GHES memory region, notifies the kernel through NMI/interrupt, then
the kernel GHES driver grabs the error record from the GHES memory
region.
>
>> With current code, GHES memory region is mapped with PAGE_KERNEL
>> based on the assumption that cache coherency of GHES memory region
>> is maintained by firmware on all platforms. This assumption is
>> not true for above mentioned arm64 platform.
>>
>> Instead GHES memory region should be mapped with page protection type
>> according to what is returned from arch_apei_get_mem_attribute().
>
> ... plus what this changelog still doesn't mention is the most important part of
> any bug fix description: how does the user notice this in practice and why does he
> care?
The changelog mentioned that Linux would read stale data from cache.
When stale data is read, kernel reports there is no new hardware error
when there actually is. This may lead to further damage in various
scenarios, such as error propagation caused data corruption.
>
> Thanks,
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
* Zhang, Jonathan Zhixiong <[email protected]> wrote:
>
>
> On 8/22/2015 2:24 AM, Ingo Molnar wrote:
> >
> >* Jonathan (Zhixiong) Zhang <[email protected]> wrote:
> >
> >>From: "Jonathan (Zhixiong) Zhang" <[email protected]>
> >>
> >>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.
> >
> >This paragraph *still* doesn't parse for me. It's not any English
> >I can recognize: what is a 'With ACPI APEI firmware first handling'?
> APEI is ACPI Platform Error Interface; it is part of ACPI spec,
> defining the aspect of hardware error handling. "firmware first
> handling" is a terminology used in APEI. It describes such mechanism
> that when hardware error happens, firmware intersects/handles such
> hardware error, formulates hardware error record and writes the record
> to GHES memory region, notifies the kernel through NMI/interrupt, then
> the kernel GHES driver grabs the error record from the GHES memory
> region.
Argh. So how about translating that to English and putting that misnomer into
scare quotes, and saying something like:
If the ACPI APEI firmware handles the error first (called "firmware first
handling"), the generic hardware error record is updated by the firmware in the
GHES memory region.
( Also note all the missing articles I added for readability. The rest of the
changelog is missing articles as well. )
> > ... plus what this changelog still doesn't mention is the most important part
> > of any bug fix description: how does the user notice this in practice and why
> > does he care?
>
> The changelog mentioned that Linux would read stale data from cache. When stale
> data is read, kernel reports there is no new hardware error when there actually
> is.
Note that this is the most valuable sentence so far, in this whole changelog and
discussion. And we needed how many emails to get to this point?
obviously saying 'stale data' in itself does not mean much - it could mean a
harmless inconsistency nobody really cares about, or in fact it could mean
something more serious:
> [...] This may lead to further damage in various scenarios, such as error
> propagation caused data corruption.
Please outline this better. How users are affected in practice is far more
important than any other detail.
Thanks,
Ingo
On 8/25/2015 1:59 AM, Ingo Molnar wrote:
>
> * Zhang, Jonathan Zhixiong <[email protected]> wrote:
>
>>
>>
>> On 8/22/2015 2:24 AM, Ingo Molnar wrote:
>>>
>>> * Jonathan (Zhixiong) Zhang <[email protected]> wrote:
>>>
>>>> From: "Jonathan (Zhixiong) Zhang" <[email protected]>
>>>>
>>>> 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.
>>>
>>> This paragraph *still* doesn't parse for me. It's not any English
>>> I can recognize: what is a 'With ACPI APEI firmware first handling'?
>> APEI is ACPI Platform Error Interface; it is part of ACPI spec,
>> defining the aspect of hardware error handling. "firmware first
>> handling" is a terminology used in APEI. It describes such mechanism
>> that when hardware error happens, firmware intersects/handles such
>> hardware error, formulates hardware error record and writes the record
>> to GHES memory region, notifies the kernel through NMI/interrupt, then
>> the kernel GHES driver grabs the error record from the GHES memory
>> region.
>
> Argh. So how about translating that to English and putting that misnomer into
> scare quotes, and saying something like:
>
> If the ACPI APEI firmware handles the error first (called "firmware first
> handling"), the generic hardware error record is updated by the firmware in the
> GHES memory region.
>
> ( Also note all the missing articles I added for readability. The rest of the
> changelog is missing articles as well. )
Thank you very much, Ingo. Input are taken.
>
>>> ... plus what this changelog still doesn't mention is the most important part
>>> of any bug fix description: how does the user notice this in practice and why
>>> does he care?
>>
>> The changelog mentioned that Linux would read stale data from cache. When stale
>> data is read, kernel reports there is no new hardware error when there actually
>> is.
>
> Note that this is the most valuable sentence so far, in this whole changelog and
> discussion. And we needed how many emails to get to this point?
>
> obviously saying 'stale data' in itself does not mean much - it could mean a
> harmless inconsistency nobody really cares about, or in fact it could mean
> something more serious:
Sure, makes sense.
>
>> [...] This may lead to further damage in various scenarios, such as error
>> propagation caused data corruption.
>
> Please outline this better. How users are affected in practice is far more
> important than any other detail.
Yes, will do. I just sent out an update for your review.
>
> Thanks,
>
> Ingo
>
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project