[U-Boot] [PATCH v2 06/12] virt-dt: Allow reservation of the secure region when it is in a RAM carveout.

[Mark Rutland]

[...]

> >> This is getting invasive:
> >>
> >> If I add carveouts via adjusting memory banks, I need to account for the
> >> case that an existing bank is split into two halves, creating additional
> >> banks this way. But then current fdt_fixup_memory_banks will no longer
> >> work due to its limitation to the number of physical banks. I could
> >> always add one spare bank to that service, ok, but then the next use
> >> case for carveouts will hit the wall again. So I better double that
> >> limit, or so.
> > 
> > Yeah, not fun.
> > 
> > If the code is position-independent then you might be able to simply
> > carve out a sufficient proportion from the start of the first entry or
> > the end of the last one, which would avoid splitting. If either of said
> > regions are too small for the monitor code then it's questionable as to
> > whether the OS can make use of it.
> 
> The code /seems/ to be position-independent, but locations are so far
> hard-coded in those places that prepare it and move it around. Maybe we
> can decide about the location at runtime, maybe we can simply demand it
> to be at the end or the beginning of some bank.

If it's possible to do so, it would seem like the nicest option to me.

> >> Also, are there any architectural or OS-implementation related
> >> restrictions on the alignment of bank start addresses and sizes? Just to
> >> make sure we don't stumble over some side effects of punching holes into
> >> that device tree node.
> > 
> > I would guess that we need to at least pad the carevout to page-aligned
> > to prevent any particular OS from mapping a page for the sake of a few
> > bytes left unused by the monitor.
> > 
> > From a quick look at the Linux arm_add_memory and memblock code it looks
> > like Linux won't map partial pages, but I don't know what Xen and others
> > do, and given we know that we want to keep the relevant pages exclusive
> > to the monitor anyway padding to age boundaries seems like a sensible
> > thing to do.
> > 
> > My one concern would be early mappings; I believe that the initial page
> > tables use (2MiB) section/block mappings to map the kernel and some
> > initial memory (including the DTB) before the memory nodes are parsed,
> > so the carevout would need to be placed away from where the kernel and
> > DTB were loaded in order to prevent those early mappings from covering
> > it. I'm unfortunately not sure on the full details there.
> 
> That makes be wonder again if we are trying to solve real issues: What
> is the OS supposed to do with a memory reserve map, what does it have to
> avoid doing with it?

Per ePAPR, memory reservation block entries may not be explicitly
accessed by the operating system (unless told to elsewhere). The OS may
map any reserved entries with cacheable attributes (potentially leading
to the issues I described earlier)

> Is the semantic really so weak that we cannot use it here?

In general, the semantic is too weak. In fact, it's not even strictly
defined for the ARM architecture w.r.t. memory attributes, so we have
very little guarantee as to what what an OS will do beyond that it will
not perform any explicit accesses to the region.

In practice, Linux will currently map the region as cacheable, and it
may or may not map it shareable depending on SMP/UP (which could be a
problem if you want to use a UP Linux to load and kexec an SMP kernel
for some reason).

It may be that on a given CPU/system implemetation that a memreserve
entry is sufficient; but unfortunately this depends on IMPLEMENTATION
DEFINED details.

Thanks,
Mark.