Re: [PATCH] kern/ieee1275/init: ppc64: Restrict high memory in presence of fadump

[Hari Bathini]

Hi Daniel,

On 22/09/23 10:48 pm, Daniel Kiper wrote:
> On Wed, Aug 02, 2023 at 11:48:18AM -0400, Stefan Berger wrote:
> > When a kernel dump is present then restrict the high memory regions to
> > avoid allocating memory where the kernel dump resides. Use the
> > ibm,kernel-dump node under /rtas to determine whether a kernel dump exists
> > and up to which limit grub can use available memory. Set the
> > upper_mem_limit to the size of the kernel dump section of type
> > 'REAL_MODE_REGION' and therefore only allow grub's memory usage for high
> > addresses from RMO_ADDR_MAX to 'upper_mem_limit'. This means that grub can
> > use high memory in the range of RMO_ADDR_MAX (768MB) to upper_mem_limit and
> > the kernel-dump memory regions above 'upper_mem_limit' remain untouched.
> > This change has no effect on memory allocations below 'linux_rmo_save'
> > (typically at 640MB).
> >
> > Also, fall back to allocating below rmo_linux_save in case the chunk of
> > memory there would be larger than the chunk of memory above RMO_ADDR_MAX.
> > This can for example occur if a free memory area is found starting at 300MB
> > extending up to 1GB but a kernel dump is located at 768MB and therefore
> > does not allow the allocation of the high memory area but requiring to use
> > the chunk starting at 300MB to avoid an unnecessary out-of-memory
> > condition.
> >
> > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>

> Please do not add RBs of folks who has not reply to an email publicly
> with their own RB. I will take this patch with Hari's RB when he
> confirms it here.

The change looks good to me. With the change applied, possible
kernel dump corruption is avoided.

Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>

> > Cc: Pavithra Prakash <pavrampu@in.ibm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
> > Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> > Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
>
> ... otherwise Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...
>
> Daniel