From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
Andrew Morton <akpm@linux-foundation.org>,
kernel test robot <lkp@intel.com>, Pingfan Liu <piliu@redhat.com>,
Kexec-ml <kexec@lists.infradead.org>,
Mimi Zohar <zohar@linux.ibm.com>,
Nayna Jain <nayna@linux.ibm.com>, Petr Tesarik <ptesarik@suse.cz>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel
Date: Wed, 15 Jul 2020 22:38:01 -0300 [thread overview]
Message-ID: <87y2nk8cjq.fsf@morokweng.localdomain> (raw)
In-Reply-To: <159466096898.24747.16701009925943468066.stgit@hbathini.in.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> @@ -968,7 +1040,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>
> /*
> * Restrict memory usage for kdump kernel by setting up
> - * usable memory ranges.
> + * usable memory ranges and memory reserve map.
> */
> if (image->type == KEXEC_TYPE_CRASH) {
> ret = get_usable_memory_ranges(&umem);
> @@ -980,6 +1052,24 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
> pr_err("Error setting up usable-memory property for kdump kernel\n");
> goto out;
> }
> +
> + ret = fdt_add_mem_rsv(fdt, BACKUP_SRC_START + BACKUP_SRC_SIZE,
> + crashk_res.start - BACKUP_SRC_SIZE);
I believe this answers my question from the other email about how the
crashkernel is prevented from stomping in the crashed kernel's memory,
right? I needed to think for a bit to understand what the above
reservation was protecting. I think it's worth adding a comment.
> + if (ret) {
> + pr_err("Error reserving crash memory: %s\n",
> + fdt_strerror(ret));
> + goto out;
> + }
> + }
> +
> + if (image->arch.backup_start) {
> + ret = fdt_add_mem_rsv(fdt, image->arch.backup_start,
> + BACKUP_SRC_SIZE);
> + if (ret) {
> + pr_err("Error reserving memory for backup: %s\n",
> + fdt_strerror(ret));
> + goto out;
> + }
> }
This is only true for KEXEC_TYPE_CRASH, if I'm following the code
correctly. I think it would be clearer to put the if above inside the if
for KEXEC_TYPE_CRASH to make it clearer.
>
> ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
<snip>
> diff --git a/arch/powerpc/purgatory/purgatory_64.c b/arch/powerpc/purgatory/purgatory_64.c
> new file mode 100644
> index 0000000..1eca74c
> --- /dev/null
> +++ b/arch/powerpc/purgatory/purgatory_64.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * purgatory: Runs between two kernels
> + *
> + * Copyright 2020, Hari Bathini, IBM Corporation.
> + */
> +
> +#include <asm/purgatory.h>
> +#include <asm/crashdump-ppc64.h>
> +
> +extern unsigned long backup_start;
> +
> +static void *__memcpy(void *dest, const void *src, unsigned long n)
> +{
> + unsigned long i;
> + unsigned char *d;
> + const unsigned char *s;
> +
> + d = dest;
> + s = src;
> + for (i = 0; i < n; i++)
> + d[i] = s[i];
> +
> + return dest;
> +}
> +
> +void purgatory(void)
> +{
> + void *dest, *src;
> +
> + src = (void *)BACKUP_SRC_START;
> + if (backup_start) {
> + dest = (void *)backup_start;
> + __memcpy(dest, src, BACKUP_SRC_SIZE);
> + }
> +}
In general I'm in favor of using C code over assembly, but having to
bring in that relocation support just for the above makes me wonder if
it's worth it in this case.
--
Thiago Jung Bauermann
IBM Linux Technology Center
next prev parent reply other threads:[~2020-07-16 1:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 17:20 [PATCH v3 00/12] ppc64: enable kdump support for kexec_file_load syscall Hari Bathini
2020-07-13 17:20 ` [PATCH v3 01/12] kexec_file: allow archs to handle special regions while locating memory hole Hari Bathini
2020-07-14 21:00 ` Thiago Jung Bauermann
2020-07-13 17:21 ` [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code Hari Bathini
2020-07-16 1:49 ` Thiago Jung Bauermann
2020-07-17 4:46 ` Hari Bathini
2020-07-17 18:34 ` Thiago Jung Bauermann
2020-07-13 17:21 ` [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges Hari Bathini
2020-07-14 23:49 ` Thiago Jung Bauermann
2020-07-16 21:08 ` Hari Bathini
2020-07-17 4:32 ` Hari Bathini
2020-07-17 20:00 ` Hari Bathini
2020-07-13 17:21 ` [PATCH v3 04/12] ppc64/kexec_file: avoid stomping memory used by special regions Hari Bathini
2020-07-15 2:39 ` Thiago Jung Bauermann
2020-07-16 5:58 ` Thiago Jung Bauermann
2020-07-16 21:09 ` Hari Bathini
2020-07-16 21:59 ` Thiago Jung Bauermann
2020-07-13 17:21 ` [PATCH v3 05/12] powerpc/drmem: make lmb walk a bit more flexible Hari Bathini
2020-07-15 3:50 ` Thiago Jung Bauermann
2020-07-16 21:09 ` Hari Bathini
2020-07-16 22:01 ` Thiago Jung Bauermann
2020-07-13 17:22 ` [PATCH v3 06/12] ppc64/kexec_file: restrict memory usage of kdump kernel Hari Bathini
2020-07-15 22:52 ` Thiago Jung Bauermann
2020-07-16 21:10 ` Hari Bathini
2020-07-16 22:03 ` Thiago Jung Bauermann
2020-07-17 4:17 ` Hari Bathini
2020-07-13 17:22 ` [PATCH v3 07/12] ppc64/kexec_file: add support to relocate purgatory Hari Bathini
2020-07-16 0:20 ` Thiago Jung Bauermann
2020-07-16 21:11 ` Hari Bathini
2020-07-16 22:12 ` Thiago Jung Bauermann
2020-07-13 17:22 ` [PATCH v3 08/12] ppc64/kexec_file: setup the stack for purgatory Hari Bathini
2020-07-16 0:35 ` Thiago Jung Bauermann
2020-07-16 1:40 ` Thiago Jung Bauermann
2020-07-13 17:22 ` [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel Hari Bathini
2020-07-16 1:38 ` Thiago Jung Bauermann [this message]
2020-07-16 21:10 ` Hari Bathini
2020-07-16 22:06 ` Thiago Jung Bauermann
2020-07-13 17:23 ` [PATCH v3 10/12] ppc64/kexec_file: prepare elfcore header for crashing kernel Hari Bathini
2020-07-16 2:22 ` Thiago Jung Bauermann
2020-07-16 21:07 ` Hari Bathini
2020-07-16 21:57 ` Thiago Jung Bauermann
2020-07-13 17:23 ` [PATCH v3 11/12] ppc64/kexec_file: add appropriate regions for memory reserve map Hari Bathini
2020-07-16 2:27 ` Thiago Jung Bauermann
2020-07-13 17:23 ` [PATCH v3 12/12] ppc64/kexec_file: fix kexec load failure with lack of memory hole Hari Bathini
2020-07-16 5:43 ` Thiago Jung Bauermann
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=87y2nk8cjq.fsf@morokweng.localdomain \
--to=bauerman@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hbathini@linux.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=lkp@intel.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=piliu@redhat.com \
--cc=ptesarik@suse.cz \
--cc=sourabhjain@linux.ibm.com \
--cc=vgoyal@redhat.com \
--cc=zohar@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).