| Message ID | 148907087368.3574.8071537539290192784.stgit@hbathini.in.ibm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
Hari Bathini <hbathini@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 <hbathini@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
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); size = get_fadump_area_size(); - base = memory_boundary - size; + WARN_ON((base + size) > memory_boundary); memblock_reserve(base, size); printk(KERN_INFO "Reserved %ldMB of memory at %ldMB " "for firmware-assisted dump\n",
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 <hbathini@linux.vnet.ibm.com> --- arch/powerpc/kernel/fadump.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)