Thread (1 message) 1 message, 1 author, 2016-07-06

[Question] Memory attribute reserved by Device Tree?

From: Ard Biesheuvel <hidden>
Date: 2016-07-06 05:34:58
Also in: linux-devicetree

On 6 July 2016 at 06:10, Masahiro Yamada [off-list ref] wrote:
2016-06-30 21:26 GMT+09:00 Mark Rutland [off-list ref]:
quoted
On Thu, Jun 30, 2016 at 12:39:03PM +0100, Robin Murphy wrote:
quoted
On 30/06/16 12:10, Masahiro Yamada wrote:
quoted
Hello.

Which memory attribute will ARM/ARM64 Linux
set to the memory region reserved by
/memreserve/ of Device Tree?


Normal memory non-cacheable?
Or, cacheable?
Or, not defined?

Perhaps actual behavior depends on whether the reserved area is
located in the low-memory region?
Isn't the point of memreserve that the kernel avoids mapping it at all?
Not quite. A /memreserve/ allows the kernel to map a region, so long as
it doesn't use the region for general allocation.

While not strictly defined for arm64 today, in practice the kernel may
map a region with Normal Inner-Shareable Inner-WB Outer-WB attributes,
following similar behaviour for PPC as defined in ePAPR.

Generally I would advise against the use of a memreserve, and favour
carving memory out of memory nodes as required, as that imposes stricter
requirements.
quoted
If a reserved region is later mapped in by a driver using
dma_declare_coherent_memory(), ioremap(), memremap() or whatever else,
then the attributes will vary depending on the exact method used.
Indeed. This applies even with the above.

Hi Robin, Mark,


Thanks for clarification!


My motivation is to try my own implementation of PSCI for my ARMv7 SoC.

I put my PSCI firmware somewhere in the DRAM region and
protected it with /memreserve/, but I was not sure what kind of memory attribute
is used for the area.
As Mark implies, /memreserve/ entries are not suitable for this, and
you should create an entry under /reserved-memory instead (please
check the bindings under Documentation/ for details). This not only
allows you to add a no-map attribute to prevent the kernel from
mapping it (which allows you to map it any way you like), it also
guarantees that the reservation is honoured even when booting via
UEFI, as /memreserve/s are ignored in this case.

Note that the difference between the handling of /memreserve/ and
/reserved-memory under UEFI is arbitrary, and should be fixed imo.

Original issue is here, as yet unresolved:
http://thread.gmane.org/gmane.linux.kernel.efi/6464
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help