On 2019-07-16 17:03:38 Tue, Hari Bathini wrote: > Add support in the kernel to process the crash'ed kernel's memory > preserved during MPIPL and export it as /proc/vmcore file for the > userland scripts to filter and analyze it later. > > Signed-off-by: Hari Bathini <hbath...@linux.ibm.com> > --- > arch/powerpc/platforms/powernv/opal-fadump.c | 190 > ++++++++++++++++++++++++++ > 1 file changed, 187 insertions(+), 3 deletions(-) > [...] > + ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_KERNEL, &addr); > + if ((ret != OPAL_SUCCESS) || !addr) { > + pr_err("Failed to get Kernel metadata (%lld)\n", ret); > + return 1; > + } > + > + addr = be64_to_cpu(addr); > + pr_debug("Kernel metadata addr: %llx\n", addr); > + > + opal_fdm_active = __va(addr); > + r_opal_fdm_active = (void *)addr; > + if (r_opal_fdm_active->version != OPAL_FADUMP_VERSION) { > + pr_err("FADump active but version (%u) unsupported!\n", > + r_opal_fdm_active->version); > + return 1; > + } > + > + /* Kernel regions not registered with f/w for MPIPL */ > + if (r_opal_fdm_active->registered_regions == 0) { > + opal_fdm_active = NULL;
What about partial dump capture scenario ? What if opal crashes while kernel was in middle of registering ranges ? We may have partial dump captured which won't be useful. e,g. If we have total of 4 ranges to be registered and opal crashes after successful registration of only 2 ranges with 2 pending, we will get a partial dump which needs to be ignored. I think check shuold be comparing registered_regions against total number of regions. What do you think ? Thanks, -Mahesh. > + return 1; > + } > + > + pr_info("Firmware-assisted dump is active.\n"); > + fadump_conf->dump_active = 1; > + opal_fadump_get_config(fadump_conf, r_opal_fdm_active); > + } > + > return 1; > } > -- Mahesh J Salgaonkar