On 6 July 2016 at 11:34, Mark Rutland <mark.rutland@xxxxxxx> 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@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
