Memory reserved by opensbi not indicated in devicetree on qemu virt platform? about opensbi

Why not use another argument register to pass a pointer to a list with free/usable memory regions? That would be the simplest solution.

[avpatel]

Yes, we are aware of the need to update reserved memory details in DTB.

Many thanks for bringing up this topic.

We are mostly booting Linux as S-mode OS so we never noticed this issue because we boot Linux from next 2MB aligned address after RAM start at 0x80200000 and Linux OF automatically reserves memory range from RAM start to Linux boot address (i.e. 0x80000000 to 0x80200000). Due to this, we kept ignoring this issue.

Of course, we should consider any possible S-Mode client and we should reserve 128KB of memory from RAM start (i.e. memory typically used by OpenSBI firmware) using reserved memory DT binding.

[atishp04]

This would mean we edit device tree for all the platforms. The approach would be to provide additional SBI calls to provide PMP protected address, which is not super nice either.

This should be a common scenario for any other ISA as well. Do we know how does it work in ARM world ?

I am not entirely opposed to the idea. Just thinking if there is a better way to do it.

[jmi2k]

What about providing a standard way of querying memory regions from supervisor mode through an extension? It's required very early during boot, yet a FDT parser is needed in the payload in order to obtain a memory map (which is redundant given that OpenSBI already walks the DT). Doing so would allow the kernel to get reliable information about the memory available on-demand from the firmware, and the firmware could override that information at will.

[jmi2k]

I imagine an scenario where changing that information at runtime would be desirable and an extension would give more flexibility, but probably I'm over-engineering. A pointer as an argument is simple and desirable if the info is not going to change though. I think some discussion and careful consideration is needed.

[fintelia]

You don't need a full device tree parser to extract the memory reservation block from a DTB. Getting that information is super simple: there is a header with a field specifying the offset from the start of the DTB to an array of 64-bit address+size pairs listing out the reserved regions of memory. The first entry with size=0 indicates the end of the list. The only complication is that all the values are in big endian but implementing a bswap function isn't that hard.

It sounded to me like the concern seemed to be mostly about having to touch the FDT in the firmware at all. You could also argue that it'd still kind of annoying to get to that part of the FDT (I know, it's basically just about reading an offset in the FDT header and then jumping to it).
If you parse the FDT much later in the boot process, you'd still need to have 2 pieces of code which read the FDT somehow.
But sure, could be a non-issue.

[jmi2k]

Well I think I'm going to create another issue as it seems I've hijacked this one

[avpatel]

I believe we can close this issue because memory reservation in DT is now done by OpenSBI.