[Skiboot] [PATCH v2] mpipl: Rework memory reservation for OPAL dump

[Oliver O'Halloran]

On Tue, Feb 11, 2020 at 3:31 AM Vasant Hegde
<hegdevasant at linux.vnet.ibm.com> wrote:
>
> On 2/10/20 9:46 PM, Vasant Hegde wrote:
> > During boot, OPAL reserves memory required to capture OPAL dump and
> > architected register data. During MPIPL, hostboot will copy OPAL dump
> > to this memory. Post MPIPL kernel will use this memory to create opalcore.
> > We use mem_reserve_fw() for this reservation. At present this reservation
> > happens late in the init path. It may clash with memory allocated by
> > local_alloc().
> >
> > We have two option to fix above issue:
> >    - Use local_alloc() for allocating memory for OPAL dump
> >      This works fine on first boot. We can use this method to reserve
> >      memory. But Post MPIPL we still want to reserve destination
> >      memory to make sure no one is stomping this area. Also this reservation
> >      might have happened in between other local_allocations. So in Post MPIPL
> >      boot allocator may not find enough memory in first region for other
> >      local_alloc() requests and may throw mem_alloc() error before trying to
> >      allocate from other regions.
> >
> >    - Early memory reservation for OPAL dump
> >      Allocate and reserve memory just after memory region init. >
> >
> > This patch uses second approach to fix reservation issue.
> >
> > Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>
>
> Missed to mention changes in v2:
>    - V1 fix borke mambo boot as it assumed `opal_node` is created before memory
> region init. Its fixed in v2.

Merged as b0e024216a3b1d35aa2273b6f64742db7ae49861.

We should fix the region splitting so it handles splitting a region
with memory allocations a little more gracefully. Oh well.

>
> -Vasant
>