Re: [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory

["Zhang, Jonathan Zhixiong" <zjzhang@codeaurora.org>]

Hi Matt/Borislav, thanks for the discussion. I am sorry that somehow
I did not see this message in my inbox. I found it by surprise through
an internet search.

> On Mon, 22 Jun, at 06:11:31AM, Matt Fleming wrote:
>>
>> Right, but see my previous comment about x86 discarding a bunch of
>> attributes for memory regions because the kernel "knows better".
>>
>> And in most places, yes, the kernel really does know better. But this
>> APEI case is special because irrespective of what the kernel says we
>> want to be compatible with the firmware's memory map.
>>
>> And we don't have an API for that.
>
> Maybe what we want is a new PAGE_* protection that is compatible with
> any firmware mappings? That'd be nice because we wouldn't have to
> introduce a whole new API for this GHES case and ioremap_* could do
> whatever it wanted under the hood.
>
> Thougts?
>
Agree. That being said, I do not know if this GHES case is the only
user case that will benefit from such framework. If it is, then it may
be controversial to introduce a framework for only one use case.

To me, there are two ways that will help GHES case:
a. Define ioremap_page_range_[no]cache() functions for archs, similar
like the case for ioremap_[no]cache.
b. Define a set of PAGE_* protection types (in particular
PAGE_KERNEL_NOCACHE). Right now it seems like only a few protection
types (such as PAGE_KERNEL) are defined across the archs.

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project