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 v10 8/8] x86/crash: Add x86 crash hotplug support
Date: Sat, 13 Aug 2022 08:34:10 +0800 [thread overview]
Message-ID: <Yvbxgvk+5HqEl7J2@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220721181747.1640-9-eric.devolder@oracle.com>
On 07/21/22 at 02:17pm, Eric DeVolder wrote:
...snip....
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e58798f636d4..bb59596c8bea 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2065,6 +2065,17 @@ config CRASH_DUMP
> (CONFIG_RELOCATABLE=y).
> For more details see Documentation/admin-guide/kdump/kdump.rst
>
> +config CRASH_MAX_MEMORY_RANGES
> + depends on CRASH_DUMP && KEXEC_FILE && (HOTPLUG_CPU || MEMORY_HOTPLUG)
> + int
> + default 32768
Do we need to enforce the value with page align and minimal size? I
checked crash_load_segments() in arch/x86/kernel/crash.c, it does the
page size aligning in kexec_add_buffer(). And in
load_crashdump_segments() of
kexec-tools/kexec/arch/i386/crashdump-x86.c, it creates elfcorehdr at
below code, the align is 1024, and in generic add_buffer()
implementation, it enforces the memsz page aligned, and changes the
passed align as page alignment.
elfcorehdr = add_buffer(info, tmp, bufsz, memsz, align, min_base,
max_addr, -1);
Maybe we should at least mention this in the help text to notice people.
> + help
> + For the kexec_file_load path, specify the maximum number of
> + memory regions, eg. as represented by the 'System RAM' entries
> + in /proc/iomem, that the elfcorehdr buffer/segment can accommodate.
> + This value is combined with NR_CPUS and multiplied by Elf64_Phdr
> + size to determine the final buffer size.
> +
> config KEXEC_JUMP
> bool "kexec jump"
> depends on KEXEC && HIBERNATION
> diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h
> index 8b6bd63530dc..96051d8e4b45 100644
> --- a/arch/x86/include/asm/crash.h
> +++ b/arch/x86/include/asm/crash.h
> @@ -9,4 +9,24 @@ int crash_setup_memmap_entries(struct kimage *image,
> struct boot_params *params);
> void crash_smp_send_stop(void);
>
> +void *arch_map_crash_pages(unsigned long paddr, unsigned long size);
> +#define arch_map_crash_pages arch_map_crash_pages
> +
> +void arch_unmap_crash_pages(void **ptr);
> +#define arch_unmap_crash_pages arch_unmap_crash_pages
> +
> +void arch_crash_handle_hotplug_event(struct kimage *image,
> + unsigned int hp_action, unsigned int cpu);
> +#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +static inline int crash_hotplug_cpu_support(void) { return 1; }
> +#define crash_hotplug_cpu_support crash_hotplug_cpu_support
> +#endif
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +static inline int crash_hotplug_memory_support(void) { return 1; }
> +#define crash_hotplug_memory_support crash_hotplug_memory_support
> +#endif
> +
> #endif /* _ASM_X86_CRASH_H */
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ceb93c176a6..55dda4fcde6e 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -25,6 +25,7 @@
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> #include <linux/memblock.h>
> +#include <linux/highmem.h>
>
> #include <asm/processor.h>
> #include <asm/hardirq.h>
> @@ -397,7 +398,17 @@ int crash_load_segments(struct kimage *image)
> image->elf_headers = kbuf.buffer;
> image->elf_headers_sz = kbuf.bufsz;
>
> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
> + /* Ensure elfcorehdr segment large enough for hotplug changes */
> + kbuf.memsz = (CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES) * sizeof(Elf64_Phdr);
Do we need to break the line to 80 chars?
> + /* For marking as usable to crash kernel */
> + image->elf_headers_sz = kbuf.memsz;
Do we need this code comment?
> + /* Record the index of the elfcorehdr segment */
> + image->elfcorehdr_index = image->nr_segments;
And this place?
> + image->elfcorehdr_index_valid = true;
> +#else
> kbuf.memsz = kbuf.bufsz;
> +#endif
> kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer(&kbuf);
> @@ -412,3 +423,107 @@ int crash_load_segments(struct kimage *image)
> return ret;
> }
> #endif /* CONFIG_KEXEC_FILE */
> +
> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
> +void *arch_map_crash_pages(unsigned long paddr, unsigned long size)
> +{
> + /*
> + * NOTE: The addresses and sizes passed to this routine have
> + * already been fully aligned on page boundaries. There is no
> + * need for massaging the address or size.
> + */
Can we move the code comment above function interface?
> + void *ptr = NULL;
> +
> + /* NOTE: requires arch_kexec_[un]protect_crashkres() for write access */
Do we need this code comment? On ARCH where proctionion is made, we
surely need to the protect/unprotect.
> + if (size > 0) {
> + struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
> +
> + ptr = kmap_local_page(page);
> + }
> +
> + return ptr;
> +}
> +
> +void arch_unmap_crash_pages(void **ptr)
> +{
> + if (ptr) {
> + if (*ptr)
> + kunmap_local(*ptr);
> + *ptr = NULL;
> + }
> +}
> +
> +/**
> + * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
> + * @image: the active struct kimage
> + * @hp_action: the hot un/plug action being handled
> + * @cpu: when KEXEC_CRASH_HP_ADD/REMOVE_CPU, the cpu affected
> + *
> + * To accurately reflect hot un/plug changes, the elfcorehdr (which
> + * is passed to the crash kernel via the elfcorehdr= parameter)
> + * must be updated with the new list of CPUs and memories. The new
> + * elfcorehdr is prepared in a kernel buffer, and then it is
> + * written on top of the existing/old elfcorehdr.
> + *
> + * For hotplug changes to elfcorehdr to work, two conditions are
> + * needed:
> + * First, the segment containing the elfcorehdr must be large enough
> + * to permit a growing number of resources. See the
> + * CONFIG_CRASH_MAX_MEMORY_RANGES description.
> + * Second, purgatory must explicitly exclude the elfcorehdr from the
> + * list of segments it checks (since the elfcorehdr changes and thus
> + * would require an update to purgatory itself to update the digest).
Isn't this generic concept to crash hotplug? Should we move it out to
some generic place?
> + *
> + */
> +void arch_crash_handle_hotplug_event(struct kimage *image,
> + unsigned int hp_action, unsigned int cpu)
The passed in 'cpu' is not used at all, what is it added for? I didn't
see explanation about it.
> +{
> + struct kexec_segment *ksegment;
> + unsigned char *ptr = NULL;
> + unsigned long elfsz = 0;
> + void *elfbuf = NULL;
> + unsigned long mem, memsz;
> +
> + /*
> + * Elfcorehdr_index_valid checked in crash_core:handle_hotplug_event()
> + */
> + ksegment = &image->segment[image->elfcorehdr_index];
> + mem = ksegment->mem;
> + memsz = ksegment->memsz;
> +
> + /*
> + * Create the new elfcorehdr reflecting the changes to CPU and/or
> + * memory resources.
> + */
> + if (prepare_elf_headers(image, &elfbuf, &elfsz)) {
> + pr_err("crash hp: unable to prepare elfcore headers");
> + goto out;
> + }
> + if (elfsz > memsz) {
> + pr_err("crash hp: update elfcorehdr elfsz %lu > memsz %lu",
> + elfsz, memsz);
> + goto out;
> + }
> +
> + /*
> + * At this point, we are all but assured of success.
> + * Copy new elfcorehdr into destination.
> + */
> + ptr = arch_map_crash_pages(mem, memsz);
> + if (ptr) {
> + /*
> + * Temporarily invalidate the crash image while the
> + * elfcorehdr is updated.
> + */
> + xchg(&kexec_crash_image, NULL);
> + memcpy_flushcache((void *)ptr, elfbuf, elfsz);
> + xchg(&kexec_crash_image, image);
> + }
> + arch_unmap_crash_pages((void **)&ptr);
> + pr_debug("crash hp: re-loaded elfcorehdr at 0x%lx\n", mem);
> +
> +out:
> + if (elfbuf)
> + 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 v10 8/8] x86/crash: Add x86 crash hotplug support
Date: Sat, 13 Aug 2022 08:34:10 +0800 [thread overview]
Message-ID: <Yvbxgvk+5HqEl7J2@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220721181747.1640-9-eric.devolder@oracle.com>
On 07/21/22 at 02:17pm, Eric DeVolder wrote:
...snip....
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e58798f636d4..bb59596c8bea 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2065,6 +2065,17 @@ config CRASH_DUMP
> (CONFIG_RELOCATABLE=y).
> For more details see Documentation/admin-guide/kdump/kdump.rst
>
> +config CRASH_MAX_MEMORY_RANGES
> + depends on CRASH_DUMP && KEXEC_FILE && (HOTPLUG_CPU || MEMORY_HOTPLUG)
> + int
> + default 32768
Do we need to enforce the value with page align and minimal size? I
checked crash_load_segments() in arch/x86/kernel/crash.c, it does the
page size aligning in kexec_add_buffer(). And in
load_crashdump_segments() of
kexec-tools/kexec/arch/i386/crashdump-x86.c, it creates elfcorehdr at
below code, the align is 1024, and in generic add_buffer()
implementation, it enforces the memsz page aligned, and changes the
passed align as page alignment.
elfcorehdr = add_buffer(info, tmp, bufsz, memsz, align, min_base,
max_addr, -1);
Maybe we should at least mention this in the help text to notice people.
> + help
> + For the kexec_file_load path, specify the maximum number of
> + memory regions, eg. as represented by the 'System RAM' entries
> + in /proc/iomem, that the elfcorehdr buffer/segment can accommodate.
> + This value is combined with NR_CPUS and multiplied by Elf64_Phdr
> + size to determine the final buffer size.
> +
> config KEXEC_JUMP
> bool "kexec jump"
> depends on KEXEC && HIBERNATION
> diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h
> index 8b6bd63530dc..96051d8e4b45 100644
> --- a/arch/x86/include/asm/crash.h
> +++ b/arch/x86/include/asm/crash.h
> @@ -9,4 +9,24 @@ int crash_setup_memmap_entries(struct kimage *image,
> struct boot_params *params);
> void crash_smp_send_stop(void);
>
> +void *arch_map_crash_pages(unsigned long paddr, unsigned long size);
> +#define arch_map_crash_pages arch_map_crash_pages
> +
> +void arch_unmap_crash_pages(void **ptr);
> +#define arch_unmap_crash_pages arch_unmap_crash_pages
> +
> +void arch_crash_handle_hotplug_event(struct kimage *image,
> + unsigned int hp_action, unsigned int cpu);
> +#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +static inline int crash_hotplug_cpu_support(void) { return 1; }
> +#define crash_hotplug_cpu_support crash_hotplug_cpu_support
> +#endif
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +static inline int crash_hotplug_memory_support(void) { return 1; }
> +#define crash_hotplug_memory_support crash_hotplug_memory_support
> +#endif
> +
> #endif /* _ASM_X86_CRASH_H */
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ceb93c176a6..55dda4fcde6e 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -25,6 +25,7 @@
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> #include <linux/memblock.h>
> +#include <linux/highmem.h>
>
> #include <asm/processor.h>
> #include <asm/hardirq.h>
> @@ -397,7 +398,17 @@ int crash_load_segments(struct kimage *image)
> image->elf_headers = kbuf.buffer;
> image->elf_headers_sz = kbuf.bufsz;
>
> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
> + /* Ensure elfcorehdr segment large enough for hotplug changes */
> + kbuf.memsz = (CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES) * sizeof(Elf64_Phdr);
Do we need to break the line to 80 chars?
> + /* For marking as usable to crash kernel */
> + image->elf_headers_sz = kbuf.memsz;
Do we need this code comment?
> + /* Record the index of the elfcorehdr segment */
> + image->elfcorehdr_index = image->nr_segments;
And this place?
> + image->elfcorehdr_index_valid = true;
> +#else
> kbuf.memsz = kbuf.bufsz;
> +#endif
> kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer(&kbuf);
> @@ -412,3 +423,107 @@ int crash_load_segments(struct kimage *image)
> return ret;
> }
> #endif /* CONFIG_KEXEC_FILE */
> +
> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
> +void *arch_map_crash_pages(unsigned long paddr, unsigned long size)
> +{
> + /*
> + * NOTE: The addresses and sizes passed to this routine have
> + * already been fully aligned on page boundaries. There is no
> + * need for massaging the address or size.
> + */
Can we move the code comment above function interface?
> + void *ptr = NULL;
> +
> + /* NOTE: requires arch_kexec_[un]protect_crashkres() for write access */
Do we need this code comment? On ARCH where proctionion is made, we
surely need to the protect/unprotect.
> + if (size > 0) {
> + struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
> +
> + ptr = kmap_local_page(page);
> + }
> +
> + return ptr;
> +}
> +
> +void arch_unmap_crash_pages(void **ptr)
> +{
> + if (ptr) {
> + if (*ptr)
> + kunmap_local(*ptr);
> + *ptr = NULL;
> + }
> +}
> +
> +/**
> + * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
> + * @image: the active struct kimage
> + * @hp_action: the hot un/plug action being handled
> + * @cpu: when KEXEC_CRASH_HP_ADD/REMOVE_CPU, the cpu affected
> + *
> + * To accurately reflect hot un/plug changes, the elfcorehdr (which
> + * is passed to the crash kernel via the elfcorehdr= parameter)
> + * must be updated with the new list of CPUs and memories. The new
> + * elfcorehdr is prepared in a kernel buffer, and then it is
> + * written on top of the existing/old elfcorehdr.
> + *
> + * For hotplug changes to elfcorehdr to work, two conditions are
> + * needed:
> + * First, the segment containing the elfcorehdr must be large enough
> + * to permit a growing number of resources. See the
> + * CONFIG_CRASH_MAX_MEMORY_RANGES description.
> + * Second, purgatory must explicitly exclude the elfcorehdr from the
> + * list of segments it checks (since the elfcorehdr changes and thus
> + * would require an update to purgatory itself to update the digest).
Isn't this generic concept to crash hotplug? Should we move it out to
some generic place?
> + *
> + */
> +void arch_crash_handle_hotplug_event(struct kimage *image,
> + unsigned int hp_action, unsigned int cpu)
The passed in 'cpu' is not used at all, what is it added for? I didn't
see explanation about it.
> +{
> + struct kexec_segment *ksegment;
> + unsigned char *ptr = NULL;
> + unsigned long elfsz = 0;
> + void *elfbuf = NULL;
> + unsigned long mem, memsz;
> +
> + /*
> + * Elfcorehdr_index_valid checked in crash_core:handle_hotplug_event()
> + */
> + ksegment = &image->segment[image->elfcorehdr_index];
> + mem = ksegment->mem;
> + memsz = ksegment->memsz;
> +
> + /*
> + * Create the new elfcorehdr reflecting the changes to CPU and/or
> + * memory resources.
> + */
> + if (prepare_elf_headers(image, &elfbuf, &elfsz)) {
> + pr_err("crash hp: unable to prepare elfcore headers");
> + goto out;
> + }
> + if (elfsz > memsz) {
> + pr_err("crash hp: update elfcorehdr elfsz %lu > memsz %lu",
> + elfsz, memsz);
> + goto out;
> + }
> +
> + /*
> + * At this point, we are all but assured of success.
> + * Copy new elfcorehdr into destination.
> + */
> + ptr = arch_map_crash_pages(mem, memsz);
> + if (ptr) {
> + /*
> + * Temporarily invalidate the crash image while the
> + * elfcorehdr is updated.
> + */
> + xchg(&kexec_crash_image, NULL);
> + memcpy_flushcache((void *)ptr, elfbuf, elfsz);
> + xchg(&kexec_crash_image, image);
> + }
> + arch_unmap_crash_pages((void **)&ptr);
> + pr_debug("crash hp: re-loaded elfcorehdr at 0x%lx\n", mem);
> +
> +out:
> + if (elfbuf)
> + vfree(elfbuf);
> +}
> +#endif
> --
> 2.31.1
>
next prev parent reply other threads:[~2022-08-13 0:34 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 18:17 [PATCH v10 0/8] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 1/8] crash: introduce arch/*/asm/crash.h Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-08-08 3:25 ` Baoquan He
2022-08-08 3:25 ` Baoquan He
2022-08-08 15:18 ` Eric DeVolder
2022-08-08 15:18 ` Eric DeVolder
2022-08-08 15:44 ` Rob Herring
2022-08-08 15:44 ` Rob Herring
2022-08-12 9:46 ` Baoquan He
2022-08-12 9:46 ` Baoquan He
2022-08-12 21:23 ` Eric DeVolder
2022-08-12 21:23 ` Eric DeVolder
2022-08-13 0:24 ` Baoquan He
2022-08-13 0:24 ` Baoquan He
2022-08-16 15:23 ` Eric DeVolder
2022-08-16 15:23 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 2/8] crash: move crash_prepare_elf64_headers Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 3/8] crash: prototype change for crash_prepare_elf64_headers Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 4/8] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-08-08 9:30 ` Baoquan He
2022-08-08 9:30 ` Baoquan He
2022-08-08 15:20 ` Eric DeVolder
2022-08-08 15:20 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 5/8] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 6/8] kexec: exclude hot remove cpu from elfcorehdr notes Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 7/8] crash: memory and cpu hotplug sysfs attributes Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-08-08 10:41 ` Baoquan He
2022-08-08 10:41 ` Baoquan He
2022-08-16 15:24 ` Eric DeVolder
2022-08-16 15:24 ` Eric DeVolder
2022-07-21 18:17 ` [PATCH v10 8/8] x86/crash: Add x86 crash hotplug support Eric DeVolder
2022-07-21 18:17 ` Eric DeVolder
2022-08-13 0:34 ` Baoquan He [this message]
2022-08-13 0:34 ` Baoquan He
2022-08-16 15:23 ` Eric DeVolder
2022-08-16 15:23 ` Eric DeVolder
2022-08-25 19:42 ` Eric DeVolder
2022-08-25 19:42 ` Eric DeVolder
2022-08-26 4:35 ` Baoquan He
2022-08-26 4:35 ` Baoquan He
2022-08-04 14:42 ` [PATCH v10 0/8] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2022-08-04 14:42 ` 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=Yvbxgvk+5HqEl7J2@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.