Hari Bathini <hbath...@linux.vnet.ibm.com> writes:
> Currently, the area to preserve boot memory is reserved at the top of
> RAM. This leaves fadump vulnerable to DLPAR memory remove operations.
> As memory for fadump needs to be reserved early in the boot process,
> fadump can't be registered after a DLPAR memory remove operation.
> While this problem can't be eleminated completely, the impact can be
> minimized by reserving memory at the halfway mark instead. With this
> change, fadump can register successfully after a DLPAR memory remove
> operation as long as the sum of the sizes of boot memory and memory
> removed is less than half of the total available memory.
>
> Signed-off-by: Hari Bathini <hbath...@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/fadump.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 8ff0dd4..9c85c5a 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -319,9 +319,13 @@ int __init fadump_reserve_mem(void)
> pr_debug("fadumphdr_addr = %p\n",
> (void *) fw_dump.fadumphdr_addr);
> } else {
> - /* Reserve the memory at the top of memory. */
> + /*
> + * Reserve memory at the halfway mark to minimize
> + * the impact of DLPAR memory remove operation.
> + */
> + base = PAGE_ALIGN(memory_boundary/2);
This doesn't account for holes, do we never have holes in the memory
layout on phyp?
cheers
