[Skiboot] [PATCH v2] mpipl: Rework memory reservation for OPAL dump
oohall at gmail.com
Mon Feb 17 15:00:28 AEDT 2020
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.
More information about the Skiboot