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.