linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
To: Hari Bathini <hbathini@linux.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>, Oliver <oohall@gmail.com>,
	Vasant Hegde <hegdevasant@linux.ibm.com>,
	Stewart Smith <stewart@linux.ibm.com>,
	Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH v4 19/25] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel
Date: Fri, 16 Aug 2019 10:31:11 +0530	[thread overview]
Message-ID: <20190816050111.b5ll5i7io2mkyurt@in.ibm.com> (raw)
In-Reply-To: <156327685595.27462.18212106248170156950.stgit@hbathini.in.ibm.com>

On 2019-07-16 17:04:16 Tue, Hari Bathini wrote:
> Add a new kernel config option, CONFIG_PRESERVE_FA_DUMP that ensures
> that crash data, from previously crash'ed kernel, is preserved. This
> helps in cases where FADump is not enabled but the subsequent memory
> preserving kernel boot is likely to process this crash data. One
> typical usecase for this config option is petitboot kernel.
> 
> As OPAL allows registering address with it in the first kernel and
> retrieving it after MPIPL, use it to store the top of boot memory.
> A kernel that intends to preserve crash data retrieves it and avoids
> using memory beyond this address.
> 
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
>  arch/powerpc/Kconfig                         |    9 ++
>  arch/powerpc/include/asm/fadump.h            |    9 +-
>  arch/powerpc/kernel/Makefile                 |    6 +
>  arch/powerpc/kernel/fadump-common.h          |   13 ++-
>  arch/powerpc/kernel/fadump.c                 |  128 ++++++++++++++++----------
>  arch/powerpc/kernel/prom.c                   |    4 -
>  arch/powerpc/platforms/powernv/Makefile      |    1 
>  arch/powerpc/platforms/powernv/opal-fadump.c |   59 ++++++++++++
>  arch/powerpc/platforms/powernv/opal-fadump.h |    3 +
>  9 files changed, 176 insertions(+), 56 deletions(-)
> 
[...]
>  #include "../../kernel/fadump-common.h"
>  #include "opal-fadump.h"
>  
> +
> +#ifdef CONFIG_PRESERVE_FA_DUMP
> +/*
> + * When dump is active but PRESERVE_FA_DUMP is enabled on the kernel,
> + * ensure crash data is preserved in hope that the subsequent memory
> + * preserving kernel boot is going to process this crash data.
> + */
> +int __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, ulong node)
> +{
> +	unsigned long dn;
> +	const __be32 *prop;
> +
> +	dn = of_get_flat_dt_subnode_by_name(node, "dump");
> +	if (dn == -FDT_ERR_NOTFOUND)
> +		return 1;
> +
> +	/*
> +	 * Check if dump has been initiated on last reboot.
> +	 */
> +	prop = of_get_flat_dt_prop(dn, "mpipl-boot", NULL);
> +	if (prop) {
> +		u64 addr = 0;
> +		s64 ret;
> +
> +		ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, &addr);
> +		if ((ret != OPAL_SUCCESS) || !addr) {
> +			pr_err("Failed to get boot memory tag (%lld)\n", ret);
> +			return 1;
> +		}
> +
> +		/*
> +		 * Anything below this address can be used for booting a
> +		 * capture kernel or petitboot kernel. Preserve everything
> +		 * above this address for processing crashdump.
> +		 */
> +		fadump_conf->boot_mem_top = be64_to_cpu(addr);
> +		pr_debug("Preserve everything above %lx\n",
> +			 fadump_conf->boot_mem_top);
> +
> +		pr_info("Firmware-assisted dump is active.\n");
> +		fadump_conf->dump_active = 1;
> +	}
> +
> +	return 1;
> +}
> +
> +#else /* CONFIG_PRESERVE_FA_DUMP */
>  static const struct opal_fadump_mem_struct *opal_fdm_active;
>  static const struct opal_mpipl_fadump *opal_cpu_metadata;
>  static struct opal_fadump_mem_struct *opal_fdm;
> @@ -155,6 +202,17 @@ static int opal_fadump_setup_kernel_metadata(struct fw_dump *fadump_conf)
>  		err = -EPERM;
>  	}
>  
> +	/*
> +	 * Register boot memory top address with f/w. Should be retrieved
> +	 * by a kernel that intends to preserve crash'ed kernel's memory.
> +	 */
> +	ret = opal_mpipl_register_tag(OPAL_MPIPL_TAG_BOOT_MEM,
> +				      fadump_conf->boot_mem_top);

Looks like we only register tag but never de-register ot set them to
NULL when we don't need it. Same for kernel TAG. i.e if we kexec into
new kernel which may not do fadump and if opal crashes it will present
stale tags to next kernel. I think we should set bootmem/kernel tag to
NULL in fadump_cleanup() path so that kexec path can be taken care of.

Thanks,
-Mahesh.


  reply	other threads:[~2019-08-16  5:15 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 11:31 [PATCH v4 00/25] Add FADump support on PowerNV platform Hari Bathini
2019-07-16 11:32 ` [PATCH v4 01/25] powerpc/fadump: move internal macros/definitions to a new header Hari Bathini
2019-07-16 11:32 ` [PATCH v4 02/25] powerpc/fadump: move internal code to a new file Hari Bathini
2019-07-16 11:32 ` [PATCH v4 03/25] powerpc/fadump: Improve fadump documentation Hari Bathini
2019-08-12  6:55   ` Mahesh Jagannath Salgaonkar
2019-07-16 11:32 ` [PATCH v4 04/25] pseries/fadump: move rtas specific definitions to platform code Hari Bathini
2019-07-16 11:32 ` [PATCH v4 05/25] pseries/fadump: introduce callbacks for platform specific operations Hari Bathini
2019-08-12  9:42   ` Mahesh J Salgaonkar
2019-08-14  6:39     ` Hari Bathini
2019-07-16 11:32 ` [PATCH v4 06/25] pseries/fadump: define register/un-register callback functions Hari Bathini
2019-08-12 16:01   ` Mahesh J Salgaonkar
2019-08-14  6:41     ` Hari Bathini
2019-07-16 11:32 ` [PATCH v4 07/25] pseries/fadump: move out platform specific support from generic code Hari Bathini
2019-08-13  5:16   ` Mahesh J Salgaonkar
2019-07-16 11:32 ` [PATCH v4 08/25] powerpc/fadump: use FADump instead of fadump for how it is pronounced Hari Bathini
2019-07-16 11:33 ` [PATCH v4 09/25] opal: add MPIPL interface definitions Hari Bathini
2019-07-16 11:33 ` [PATCH v4 10/25] powernv/fadump: add fadump support on powernv Hari Bathini
2019-07-16 11:33 ` [PATCH v4 11/25] powernv/fadump: register kernel metadata address with opal Hari Bathini
2019-08-13 10:41   ` Mahesh J Salgaonkar
2019-08-14  7:06     ` Hari Bathini
2019-08-14 10:21       ` Mahesh Jagannath Salgaonkar
2019-08-19 15:49         ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 12/25] powernv/fadump: define register/un-register callback functions Hari Bathini
2019-08-13 14:34   ` Mahesh J Salgaonkar
2019-08-14  7:11     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 13/25] powernv/fadump: support copying multiple kernel memory regions Hari Bathini
2019-08-13 15:03   ` Mahesh J Salgaonkar
2019-08-14  7:14     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 14/25] powernv/fadump: process the crashdump by exporting it as /proc/vmcore Hari Bathini
2019-08-14 10:18   ` Mahesh J Salgaonkar
2019-08-14 11:11     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 15/25] powerpc/fadump: Update documentation about OPAL platform support Hari Bathini
2019-07-16 11:33 ` [PATCH v4 16/25] powerpc/fadump: consider reserved ranges while reserving memory Hari Bathini
2019-07-16 11:34 ` [PATCH v4 17/25] powerpc/fadump: consider reserved ranges while releasing memory Hari Bathini
2019-07-16 11:34 ` [PATCH v4 18/25] powernv/fadump: process architected register state data provided by firmware Hari Bathini
2019-08-14 17:15   ` Mahesh J Salgaonkar
2019-08-16  2:38     ` Hari Bathini
2019-07-16 11:34 ` [PATCH v4 19/25] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel Hari Bathini
2019-08-16  5:01   ` Mahesh J Salgaonkar [this message]
2019-07-16 11:34 ` [PATCH v4 20/25] powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP Hari Bathini
2019-07-16 11:34 ` [PATCH v4 21/25] powernv/opalcore: export /sys/firmware/opal/core for analysing opal crashes Hari Bathini
2019-07-16 11:34 ` [PATCH v4 22/25] powernv/fadump: Warn before processing partial crashdump Hari Bathini
2019-08-16  5:59   ` Mahesh J Salgaonkar
2019-07-16 11:34 ` [PATCH v4 23/25] powernv/opalcore: provide an option to invalidate /sys/firmware/opal/core file Hari Bathini
2019-07-16 11:34 ` [PATCH v4 24/25] powernv/fadump: consider f/w load area Hari Bathini
2019-07-16 11:35 ` [PATCH v4 25/25] powernv/fadump: update documentation about option to release opalcore Hari Bathini
2019-07-19  6:19 ` [PATCH v4 00/25] Add FADump support on PowerNV platform Hari Bathini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190816050111.b5ll5i7io2mkyurt@in.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=ananth@linux.ibm.com \
    --cc=dja@axtens.net \
    --cc=hbathini@linux.ibm.com \
    --cc=hegdevasant@linux.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=oohall@gmail.com \
    --cc=stewart@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).