All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Hari Bathini <hbathini@linux.ibm.com>
Cc: Eric DeVolder <eric.devolder@oracle.com>,
	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 v21 5/7] x86/crash: add x86 crash hotplug support
Date: Fri, 28 Apr 2023 17:25:18 +0800	[thread overview]
Message-ID: <ZEuQ/hxmZey+eFZs@MiWiFi-R3L-srv> (raw)
In-Reply-To: <409c8253-49b9-6993-f79e-8e6203ce4b31@linux.ibm.com>

On 04/27/23 at 10:26pm, Hari Bathini wrote:
> On 27/04/23 2:19 pm, Baoquan He wrote:
> > On 04/27/23 at 12:39pm, Hari Bathini wrote:
> > > Hi Eric,
> > > 
> > > On 04/04/23 11:33 pm, Eric DeVolder wrote:
> > > > When CPU or memory is hot un/plugged, or off/onlined, the crash
> > > > elfcorehdr, which describes the CPUs and memory in the system,
> > > > must also be updated.
> > > > 
> > > > The segment containing the elfcorehdr is identified at run-time
> > > > in crash_core:crash_handle_hotplug_event(), which works for both
> > > > the kexec_load() and kexec_file_load() syscalls. A new elfcorehdr
> > > > is generated from the available CPUs and memory into a buffer,
> > > > and then installed over the top of the existing elfcorehdr.
> > > > 
> > > > In the patch 'kexec: exclude elfcorehdr from the segment digest'
> > > > the need to update purgatory due to the change in elfcorehdr was
> > > > eliminated.  As a result, no changes to purgatory or boot_params
> > > > (as the elfcorehdr= kernel command line parameter pointer
> > > > remains unchanged and correct) are needed, just elfcorehdr.
> > > > 
> > > > To accommodate a growing number of resources via hotplug, the
> > > > elfcorehdr segment must be sufficiently large enough to accommodate
> > > > changes, see the CRASH_MAX_MEMORY_RANGES description. This is used
> > > > only on the kexec_file_load() syscall; for kexec_load() userspace
> > > > will need to size the segment similarly.
> > > > 
> > > > To accommodate kexec_load() syscall in the absence of
> > > 
> > > Firstly, thanks! This series is a nice improvement to kdump support
> > > in hotplug environment.
> > > 
> > > One concern though is that this change assumes corresponding support
> > > in kexec-tools. Without that support kexec_load would fail to boot
> > > with digest verification failure, iiuc.
> > 
> > Eric has posted patchset to modify kexec_tools to support that, please
> > see the link Eric pasted in the cover letter.
> > 
> > http://lists.infradead.org/pipermail/kexec/2022-October/026032.html
> 
> Right, Baoquan.
> 
> I did see that and if I read the code correctly, without that patchset
> kexec_load would fail. Not with an explicit error that hotplug support
> is missing or such but it would simply fail to boot into capture kernel
> with digest verification failure.
> 
> My suggestion was to avoid that userspace tool breakage for older
> kexec-tools version by introducing a new kexec flag that can tell
> kernel that kexec-tools is ready to use this in-kernel update support.
> So, if kexec_load happens without the flag, avoid doing an in-kernel
> update on hotplug. I hope that clears the confusion.

Yeah, sounds like a good idea. It may be extended in later patch.


_______________________________________________
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: Hari Bathini <hbathini@linux.ibm.com>
Cc: Eric DeVolder <eric.devolder@oracle.com>,
	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 v21 5/7] x86/crash: add x86 crash hotplug support
Date: Fri, 28 Apr 2023 17:25:18 +0800	[thread overview]
Message-ID: <ZEuQ/hxmZey+eFZs@MiWiFi-R3L-srv> (raw)
In-Reply-To: <409c8253-49b9-6993-f79e-8e6203ce4b31@linux.ibm.com>

On 04/27/23 at 10:26pm, Hari Bathini wrote:
> On 27/04/23 2:19 pm, Baoquan He wrote:
> > On 04/27/23 at 12:39pm, Hari Bathini wrote:
> > > Hi Eric,
> > > 
> > > On 04/04/23 11:33 pm, Eric DeVolder wrote:
> > > > When CPU or memory is hot un/plugged, or off/onlined, the crash
> > > > elfcorehdr, which describes the CPUs and memory in the system,
> > > > must also be updated.
> > > > 
> > > > The segment containing the elfcorehdr is identified at run-time
> > > > in crash_core:crash_handle_hotplug_event(), which works for both
> > > > the kexec_load() and kexec_file_load() syscalls. A new elfcorehdr
> > > > is generated from the available CPUs and memory into a buffer,
> > > > and then installed over the top of the existing elfcorehdr.
> > > > 
> > > > In the patch 'kexec: exclude elfcorehdr from the segment digest'
> > > > the need to update purgatory due to the change in elfcorehdr was
> > > > eliminated.  As a result, no changes to purgatory or boot_params
> > > > (as the elfcorehdr= kernel command line parameter pointer
> > > > remains unchanged and correct) are needed, just elfcorehdr.
> > > > 
> > > > To accommodate a growing number of resources via hotplug, the
> > > > elfcorehdr segment must be sufficiently large enough to accommodate
> > > > changes, see the CRASH_MAX_MEMORY_RANGES description. This is used
> > > > only on the kexec_file_load() syscall; for kexec_load() userspace
> > > > will need to size the segment similarly.
> > > > 
> > > > To accommodate kexec_load() syscall in the absence of
> > > 
> > > Firstly, thanks! This series is a nice improvement to kdump support
> > > in hotplug environment.
> > > 
> > > One concern though is that this change assumes corresponding support
> > > in kexec-tools. Without that support kexec_load would fail to boot
> > > with digest verification failure, iiuc.
> > 
> > Eric has posted patchset to modify kexec_tools to support that, please
> > see the link Eric pasted in the cover letter.
> > 
> > http://lists.infradead.org/pipermail/kexec/2022-October/026032.html
> 
> Right, Baoquan.
> 
> I did see that and if I read the code correctly, without that patchset
> kexec_load would fail. Not with an explicit error that hotplug support
> is missing or such but it would simply fail to boot into capture kernel
> with digest verification failure.
> 
> My suggestion was to avoid that userspace tool breakage for older
> kexec-tools version by introducing a new kexec flag that can tell
> kernel that kexec-tools is ready to use this in-kernel update support.
> So, if kexec_load happens without the flag, avoid doing an in-kernel
> update on hotplug. I hope that clears the confusion.

Yeah, sounds like a good idea. It may be extended in later patch.


  reply	other threads:[~2023-04-28  9:25 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 18:03 [PATCH v21 0/7] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2023-04-04 18:03 ` Eric DeVolder
2023-04-04 18:03 ` [PATCH v21 1/7] crash: move a few code bits to setup support of crash hotplug Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-04 18:03 ` [PATCH v21 2/7] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-06 11:04   ` Baoquan He
2023-04-06 11:04     ` Baoquan He
2023-04-06 16:10     ` Eric DeVolder
2023-04-06 16:10       ` Eric DeVolder
2023-04-06 23:58       ` Baoquan He
2023-04-06 23:58         ` Baoquan He
2023-04-18 13:55         ` Eric DeVolder
2023-04-18 13:55           ` Eric DeVolder
2023-04-19  0:05           ` Baoquan He
2023-04-19  0:05             ` Baoquan He
2023-04-12  8:38       ` Sourabh Jain
2023-04-12  8:38         ` Sourabh Jain
2023-04-04 18:03 ` [PATCH v21 3/7] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-04 18:03 ` [PATCH v21 4/7] crash: memory and CPU hotplug sysfs attributes Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-04 18:03 ` [PATCH v21 5/7] x86/crash: add x86 crash hotplug support Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-27  7:09   ` Hari Bathini
2023-04-27  7:09     ` Hari Bathini
2023-04-27  8:49     ` Baoquan He
2023-04-27  8:49       ` Baoquan He
2023-04-27 16:56       ` Hari Bathini
2023-04-27 16:56         ` Hari Bathini
2023-04-28  9:25         ` Baoquan He [this message]
2023-04-28  9:25           ` Baoquan He
2023-04-28 18:31           ` Hari Bathini
2023-04-28 18:31             ` Hari Bathini
2023-05-01 18:33             ` Eric DeVolder
2023-05-01 18:33               ` Eric DeVolder
2023-05-02  9:36               ` Hari Bathini
2023-05-02  9:36                 ` Hari Bathini
2023-04-04 18:03 ` [PATCH v21 6/7] crash: change crash_prepare_elf64_headers() to for_each_possible_cpu() Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-04 18:03 ` [PATCH v21 7/7] x86/crash: optimize CPU changes Eric DeVolder
2023-04-04 18:03   ` Eric DeVolder
2023-04-06 11:06 ` [PATCH v21 0/7] crash: Kernel handling of CPU and memory hot un/plug Baoquan He
2023-04-06 11:06   ` Baoquan He
2023-04-06 16:12   ` Eric DeVolder
2023-04-06 16:12     ` Eric DeVolder
2023-04-27  7:08 ` Hari Bathini
2023-04-27  7:08   ` Hari Bathini
2023-05-01 18:35   ` Eric DeVolder
2023-05-01 18:35     ` 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=ZEuQ/hxmZey+eFZs@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=hbathini@linux.ibm.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.