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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
