[Question] Memory attribute reserved by Device Tree?

[Question] Memory attribute reserved by Device Tree?

[Masahiro Yamada]

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?


Thanks,


-- 
Best Regards
Masahiro Yamada

[Question] Memory attribute reserved by Device Tree?

[Robin Murphy]

On 30/06/16 12:10, Masahiro Yamada wrote:
> 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?
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.

Robin.

> 
> 
> Thanks,
> 
> 

[Question] Memory attribute reserved by Device Tree?

[Mark Rutland]

On Thu, Jun 30, 2016 at 12:39:03PM +0100, Robin Murphy wrote:
> On 30/06/16 12:10, Masahiro Yamada wrote:
> > 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.

> 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.

Thanks,
Mark.

[Question] Memory attribute reserved by Device Tree?

[Masahiro Yamada]

2016-06-30 21:26 GMT+09:00 Mark Rutland <mark.rutland@arm.com>:
> On Thu, Jun 30, 2016 at 12:39:03PM +0100, Robin Murphy wrote:
>> On 30/06/16 12:10, Masahiro Yamada wrote:
>> > 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.
>
>> 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.




-- 
Best Regards
Masahiro Yamada

[Question] Memory attribute reserved by Device Tree?

[Ard Biesheuvel]

On 6 July 2016 at 06:10, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> 2016-06-30 21:26 GMT+09:00 Mark Rutland <mark.rutland@arm.com>:
>> On Thu, Jun 30, 2016 at 12:39:03PM +0100, Robin Murphy wrote:
>>> On 30/06/16 12:10, Masahiro Yamada wrote:
>>> > 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.
>>
>>> 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

[Question] Memory attribute reserved by Device Tree?

[Mark Rutland]

On Wed, Jul 06, 2016 at 07:34:58AM +0200, Ard Biesheuvel wrote:
> On 6 July 2016 at 06:10, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> > 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).

I'd strongly recommend that the memory in question was carved out of the
memory node, rather than using a reserved-memory node. The OS has
absolutely no reason to know about this memory in the first place.

This is more robust as other agents will similarly not poke the memory.

> 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.

You'll still need to teach your UEFI implementation to reserve the
region (and to not give it cacheable attributes), to enable this, so
similarly I'd recommend that it is completely removed from the memory
map -- no agent other than the PSCI implementation has any reason to map
this memory.

Thanks,
Mark.

[Question] Memory attribute reserved by Device Tree?

[Ard Biesheuvel]

On 6 July 2016 at 11:34, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Jul 06, 2016 at 07:34:58AM +0200, Ard Biesheuvel wrote:
>> On 6 July 2016 at 06:10, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>> > 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).
>
> I'd strongly recommend that the memory in question was carved out of the
> memory node, rather than using a reserved-memory node. The OS has
> absolutely no reason to know about this memory in the first place.
>
> This is more robust as other agents will similarly not poke the memory.
>

Right, so I misunderstood your suggestion. You'd prefer the memory in
question not to be covered at all by any memory nodes. I agree this
makes the most sense.

>> 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.
>
> You'll still need to teach your UEFI implementation to reserve the
> region (and to not give it cacheable attributes), to enable this,

You'd need this in any case if you are using UEFI, unless you're
seeding its view of the memory map from the DT. So I think this is a
separate issue.

> so similarly I'd recommend that it is completely removed from the memory
> map -- no agent other than the PSCI implementation has any reason to map
> this memory.
>

Indeed. Since you are invoking PSCI via hvc or smc calls, neither the
OS nor anything else that executes at the same exception level (or
whatever we call it for ARMv7) has any business accessing it directly,
and so it does not need to know of its existence.