From: Baoquan He <bhe@redhat.com>
To: Eric DeVolder <eric.devolder@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, vgoyal@redhat.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, nramas@linux.microsoft.com,
thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de,
rppt@kernel.org, david@redhat.com, sourabhjain@linux.ibm.com,
konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v15 7/7] x86/crash: add x86 crash hotplug support
Date: Wed, 4 Jan 2023 17:08:55 +0800 [thread overview]
Message-ID: <Y7VCJ4QvBIYNnF0b@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20221209153656.3284-8-eric.devolder@oracle.com>
On 12/09/22 at 10:36am, Eric DeVolder wrote:
...... snip out
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ceb93c176a6..5186df48ce6c 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -42,6 +42,21 @@
> #include <asm/crash.h>
> #include <asm/cmdline.h>
>
> +/*
> + * For the kexec_file_load() syscall path, specify the maximum number of
> + * memory regions that the elfcorehdr buffer/segment can accommodate.
> + * These regions are obtained via walk_system_ram_res(); eg. the
> + * 'System RAM' entries in /proc/iomem.
> + * This value is combined with NR_CPUS_DEFAULT and multiplied by
> + * sizeof(Elf64_Phdr) to determine the final elfcorehdr memory buffer/
> + * segment size.
> + * The value 8192, for example, covers a (sparsely populated) 1TiB system
> + * consisting of 128MiB memblocks, while resulting in an elfcorehdr
> + * memory buffer/segment size under 1MiB. This represents a sane choice
> + * to accommodate both baremetal and virtual machine configurations.
> + */
> +#define CRASH_MAX_MEMORY_RANGES 8192
> +
> /* Used while preparing memory map entries for second kernel */
> struct crash_memmap_data {
> struct boot_params *params;
> @@ -394,10 +409,39 @@ int crash_load_segments(struct kimage *image)
> if (ret)
> return ret;
>
> - image->elf_headers = kbuf.buffer;
> - image->elf_headers_sz = kbuf.bufsz;
> + image->elf_headers = kbuf.buffer;
> + image->elf_headers_sz = kbuf.bufsz;
> + kbuf.memsz = kbuf.bufsz;
> +
> +#ifdef CONFIG_CRASH_HOTPLUG
> + if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) {
Do I miss anything important during reviewing? I can't see why memory
hotplug is also relying on HOTPLUG_CPU.
> + /*
> + * Ensure the elfcorehdr segment large enough for hotplug changes.
> + * Start with VMCOREINFO and kernel_map.
> + */
> + unsigned long pnum = 2;
> +
> + if (IS_ENABLED(CONFIG_HOTPLUG_CPU))
> + pnum += CONFIG_NR_CPUS_DEFAULT;
> +
> + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
> + pnum += CRASH_MAX_MEMORY_RANGES;
> +
> + if (pnum < (unsigned long)PN_XNUM) {
> + kbuf.memsz = pnum * sizeof(Elf64_Phdr);
> + kbuf.memsz += sizeof(Elf64_Ehdr);
> +
> + image->elfcorehdr_index = image->nr_segments;
> + image->elfcorehdr_index_valid = true;
> +
> + /* Mark as usable to crash kernel, else crash kernel fails on boot */
> + image->elf_headers_sz = kbuf.memsz;
> + } else {
> + pr_err("number of Phdrs %lu exceeds max\n", pnum);
> + }
> + }
> +#endif
>
> - kbuf.memsz = kbuf.bufsz;
> kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer(&kbuf);
> @@ -412,3 +456,67 @@ int crash_load_segments(struct kimage *image)
> return ret;
> }
> #endif /* CONFIG_KEXEC_FILE */
> +
> +#ifdef CONFIG_CRASH_HOTPLUG
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "crash hp: " fmt
> +
> +/**
> + * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
> + * @image: the active struct kimage
> + *
> + * To accurately reflect hot un/plug changes, the new elfcorehdr
> + * is prepared in a kernel buffer, and then it is written on top
> + * of the existing/old elfcorehdr.
> + */
> +void arch_crash_handle_hotplug_event(struct kimage *image)
> +{
> + void *elfbuf = NULL, *old_elfcorehdr;
> + unsigned long mem, memsz;
> + unsigned long elfsz = 0;
> +
> + /*
> + * Create the new elfcorehdr reflecting the changes to CPU and/or
> + * memory resources.
> + */
> + if (prepare_elf_headers(image, &elfbuf, &elfsz)) {
> + pr_err("unable to prepare elfcore headers");
> + goto out;
> + }
> +
> + /*
> + * Obtain address and size of the elfcorehdr segment, and
> + * check it against the new elfcorehdr buffer.
> + */
> + mem = image->segment[image->elfcorehdr_index].mem;
> + memsz = image->segment[image->elfcorehdr_index].memsz;
> + if (elfsz > memsz) {
> + pr_err("update elfcorehdr elfsz %lu > memsz %lu",
> + elfsz, memsz);
> + goto out;
> + }
> +
> + /*
> + * Copy new elfcorehdr over the old elfcorehdr at destination.
> + */
> + old_elfcorehdr = kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT));
> + if (old_elfcorehdr) {
> + pr_err("updating elfcorehdr failed\n");
> + goto out;
> + }
> +
> + /*
> + * Temporarily invalidate the crash image while the
> + * elfcorehdr is updated.
> + */
> + xchg(&kexec_crash_image, NULL);
> + memcpy_flushcache(old_elfcorehdr, elfbuf, elfsz);
> + xchg(&kexec_crash_image, image);
> + kunmap_local(old_elfcorehdr);
> + pr_debug("updated elfcorehdr\n");
> +
> +out:
> + vfree(elfbuf);
> +}
> +#endif
> --
> 2.31.1
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Eric DeVolder <eric.devolder@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, vgoyal@redhat.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, nramas@linux.microsoft.com,
thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de,
rppt@kernel.org, david@redhat.com, sourabhjain@linux.ibm.com,
konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v15 7/7] x86/crash: add x86 crash hotplug support
Date: Wed, 4 Jan 2023 17:08:55 +0800 [thread overview]
Message-ID: <Y7VCJ4QvBIYNnF0b@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20221209153656.3284-8-eric.devolder@oracle.com>
On 12/09/22 at 10:36am, Eric DeVolder wrote:
...... snip out
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ceb93c176a6..5186df48ce6c 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -42,6 +42,21 @@
> #include <asm/crash.h>
> #include <asm/cmdline.h>
>
> +/*
> + * For the kexec_file_load() syscall path, specify the maximum number of
> + * memory regions that the elfcorehdr buffer/segment can accommodate.
> + * These regions are obtained via walk_system_ram_res(); eg. the
> + * 'System RAM' entries in /proc/iomem.
> + * This value is combined with NR_CPUS_DEFAULT and multiplied by
> + * sizeof(Elf64_Phdr) to determine the final elfcorehdr memory buffer/
> + * segment size.
> + * The value 8192, for example, covers a (sparsely populated) 1TiB system
> + * consisting of 128MiB memblocks, while resulting in an elfcorehdr
> + * memory buffer/segment size under 1MiB. This represents a sane choice
> + * to accommodate both baremetal and virtual machine configurations.
> + */
> +#define CRASH_MAX_MEMORY_RANGES 8192
> +
> /* Used while preparing memory map entries for second kernel */
> struct crash_memmap_data {
> struct boot_params *params;
> @@ -394,10 +409,39 @@ int crash_load_segments(struct kimage *image)
> if (ret)
> return ret;
>
> - image->elf_headers = kbuf.buffer;
> - image->elf_headers_sz = kbuf.bufsz;
> + image->elf_headers = kbuf.buffer;
> + image->elf_headers_sz = kbuf.bufsz;
> + kbuf.memsz = kbuf.bufsz;
> +
> +#ifdef CONFIG_CRASH_HOTPLUG
> + if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) {
Do I miss anything important during reviewing? I can't see why memory
hotplug is also relying on HOTPLUG_CPU.
> + /*
> + * Ensure the elfcorehdr segment large enough for hotplug changes.
> + * Start with VMCOREINFO and kernel_map.
> + */
> + unsigned long pnum = 2;
> +
> + if (IS_ENABLED(CONFIG_HOTPLUG_CPU))
> + pnum += CONFIG_NR_CPUS_DEFAULT;
> +
> + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
> + pnum += CRASH_MAX_MEMORY_RANGES;
> +
> + if (pnum < (unsigned long)PN_XNUM) {
> + kbuf.memsz = pnum * sizeof(Elf64_Phdr);
> + kbuf.memsz += sizeof(Elf64_Ehdr);
> +
> + image->elfcorehdr_index = image->nr_segments;
> + image->elfcorehdr_index_valid = true;
> +
> + /* Mark as usable to crash kernel, else crash kernel fails on boot */
> + image->elf_headers_sz = kbuf.memsz;
> + } else {
> + pr_err("number of Phdrs %lu exceeds max\n", pnum);
> + }
> + }
> +#endif
>
> - kbuf.memsz = kbuf.bufsz;
> kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer(&kbuf);
> @@ -412,3 +456,67 @@ int crash_load_segments(struct kimage *image)
> return ret;
> }
> #endif /* CONFIG_KEXEC_FILE */
> +
> +#ifdef CONFIG_CRASH_HOTPLUG
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "crash hp: " fmt
> +
> +/**
> + * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
> + * @image: the active struct kimage
> + *
> + * To accurately reflect hot un/plug changes, the new elfcorehdr
> + * is prepared in a kernel buffer, and then it is written on top
> + * of the existing/old elfcorehdr.
> + */
> +void arch_crash_handle_hotplug_event(struct kimage *image)
> +{
> + void *elfbuf = NULL, *old_elfcorehdr;
> + unsigned long mem, memsz;
> + unsigned long elfsz = 0;
> +
> + /*
> + * Create the new elfcorehdr reflecting the changes to CPU and/or
> + * memory resources.
> + */
> + if (prepare_elf_headers(image, &elfbuf, &elfsz)) {
> + pr_err("unable to prepare elfcore headers");
> + goto out;
> + }
> +
> + /*
> + * Obtain address and size of the elfcorehdr segment, and
> + * check it against the new elfcorehdr buffer.
> + */
> + mem = image->segment[image->elfcorehdr_index].mem;
> + memsz = image->segment[image->elfcorehdr_index].memsz;
> + if (elfsz > memsz) {
> + pr_err("update elfcorehdr elfsz %lu > memsz %lu",
> + elfsz, memsz);
> + goto out;
> + }
> +
> + /*
> + * Copy new elfcorehdr over the old elfcorehdr at destination.
> + */
> + old_elfcorehdr = kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT));
> + if (old_elfcorehdr) {
> + pr_err("updating elfcorehdr failed\n");
> + goto out;
> + }
> +
> + /*
> + * Temporarily invalidate the crash image while the
> + * elfcorehdr is updated.
> + */
> + xchg(&kexec_crash_image, NULL);
> + memcpy_flushcache(old_elfcorehdr, elfbuf, elfsz);
> + xchg(&kexec_crash_image, image);
> + kunmap_local(old_elfcorehdr);
> + pr_debug("updated elfcorehdr\n");
> +
> +out:
> + vfree(elfbuf);
> +}
> +#endif
> --
> 2.31.1
>
next prev parent reply other threads:[~2023-01-04 10:16 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 15:36 [PATCH v15 0/7] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 1/7] crash: move crash_prepare_elf64_headers() Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2023-01-09 5:05 ` Sourabh Jain
2023-01-09 5:05 ` Sourabh Jain
2023-01-09 19:40 ` Eric DeVolder
2023-01-09 19:40 ` Eric DeVolder
2023-01-12 17:23 ` Eric DeVolder
2023-01-12 17:23 ` Eric DeVolder
2023-01-16 16:30 ` Petr Tesařík
2023-01-16 16:30 ` Petr Tesařík
2023-01-17 22:33 ` Eric DeVolder
2023-01-17 22:33 ` Eric DeVolder
2023-01-19 3:09 ` Sourabh Jain
2023-01-19 3:09 ` Sourabh Jain
2022-12-09 15:36 ` [PATCH v15 2/7] crash: prototype change for crash_prepare_elf64_headers() Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 3/7] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2023-01-04 8:34 ` Baoquan He
2023-01-04 8:34 ` Baoquan He
2023-01-04 16:18 ` Eric DeVolder
2023-01-04 16:18 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 4/7] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 5/7] kexec: exclude hot remove cpu from elfcorehdr notes Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 6/7] crash: memory and cpu hotplug sysfs attributes Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2022-12-09 15:36 ` [PATCH v15 7/7] x86/crash: add x86 crash hotplug support Eric DeVolder
2022-12-09 15:36 ` Eric DeVolder
2023-01-04 9:08 ` Baoquan He [this message]
2023-01-04 9:08 ` Baoquan He
2023-01-04 16:20 ` Eric DeVolder
2023-01-04 16:20 ` Eric DeVolder
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=Y7VCJ4QvBIYNnF0b@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=eric.devolder@oracle.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nramas@linux.microsoft.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.