All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Akhil Raj <lf32.dev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Dave Young <dyoung@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Eric DeVolder <eric.devolder@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Laurent Dufour <laurent.dufour@fr.ibm.com>,
	Mahesh Salgaonkar <mahesh@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Naveen N Rao <naveen@kernel.org>,
	Oscar Salvador <osalvador@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	kexec@lists.infradead.org, x86@kernel.org
Subject: Re: [PATCH v14 3/6] crash: add a new kexec flag for FDT update
Date: Fri, 22 Dec 2023 08:28:23 +0800	[thread overview]
Message-ID: <ZYTYJ6sjdzZwjGpS@MiWiFi-R3L-srv> (raw)
In-Reply-To: <cdde877b-e620-45db-ae28-4b691c1ae5b6@linux.ibm.com>

On 12/21/23 at 11:36am, Sourabh Jain wrote:
......
> > > > diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> > > > index 3d5b3d757bed..df6a6505e267 100644
> > > > --- a/include/uapi/linux/kexec.h
> > > > +++ b/include/uapi/linux/kexec.h
> > > > @@ -13,7 +13,7 @@
> > > >    #define KEXEC_ON_CRASH         0x00000001
> > > >    #define KEXEC_PRESERVE_CONTEXT 0x00000002
> > > > -#define KEXEC_UPDATE_FDT       0x00000008
> > > > +#define KEXEC_CRASH_HOTPLUG_UPDATE 0x00000004
> > > >    #define KEXEC_UPDATE_ELFCOREHDR        0x00000004
> > > >    #define KEXEC_ARCH_MASK                0xffff0000
> > > >    /*
> > > > 
> > > > With my understanding, the kexec flag should be indicating the action,
> > > > the mem/cpu hotplug, but not relating to any detail. Imagine later
> > > > another segment need be skipped on one ARCH again, then another flag
> > > > need be added, this sounds not reasonable.
> > > I strongly agree with you. The KEXEC_CRASH_HOTPLUG_UPDATE kexec flag
> > > should be sufficient to inform the kernel that the kexec tool has been
> > > updated
> > > to support CPU/Memory hotplug for the kexec_load system call. Unfortunately,
> > > we cannot use the 0x00000004 kexec flags bit for KEXEC_CRASH_HOTPLUG_UPDATE
> > > at the moment.
> > I am fine with 0x00000008 and a new flag, it has the same effect as
> > #define KEXEC_CRASH_HOTPLUG_UPDATE 0x00000004
> > 
> > I am worried about the header file incompatiblity.
> 
> If we are OK to have KEXEC_CRASH_HOTPLUG_UPDATE 0x00000008 as new bit
> to introduce CPU/Memory hotplug feature for kexec_load syscall, we will not
> have
> compatibility issue.
> 
> Let me write next version for this patch with KEXEC_CRASH_HOTPLUG_UPDATE
> 0x00000008
> as new flag bit and show how it will be handled. I will also share kexec
> code for clarity.

It's great we are in the same page about segments excluding done in arch
function. While It's a little unclear to me why we can't reuse 0x00000004
flag value. Then KEXEC_UPDATE_ELFCOREHDR will only exist in v6.6 kernel,
and that bit won't be used in v6.7 and future version.

Except of the existence in kexec-tools utility for XEN, do you see other
barrier? I would like to know so that one day I can explain
KEXEC_UPDATE_ELFCOREHDR to someone else if asked.


_______________________________________________
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: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	linuxppc-dev@ozlabs.org, Eric DeVolder <eric.devolder@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Valentin Schneider <vschneid@redhat.com>,
	x86@kernel.org, "Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
	Laurent Dufour <laurent.dufour@fr.ibm.com>,
	Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
	Naveen N Rao <naveen@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Oscar Salvador <osalvador@suse.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kexec@lists.infradead.org,
	Mahesh Salgaonkar <mahesh@linux.ibm.com>,
	Akhil Raj <lf32.dev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v14 3/6] crash: add a new kexec flag for FDT update
Date: Fri, 22 Dec 2023 08:28:23 +0800	[thread overview]
Message-ID: <ZYTYJ6sjdzZwjGpS@MiWiFi-R3L-srv> (raw)
In-Reply-To: <cdde877b-e620-45db-ae28-4b691c1ae5b6@linux.ibm.com>

On 12/21/23 at 11:36am, Sourabh Jain wrote:
......
> > > > diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> > > > index 3d5b3d757bed..df6a6505e267 100644
> > > > --- a/include/uapi/linux/kexec.h
> > > > +++ b/include/uapi/linux/kexec.h
> > > > @@ -13,7 +13,7 @@
> > > >    #define KEXEC_ON_CRASH         0x00000001
> > > >    #define KEXEC_PRESERVE_CONTEXT 0x00000002
> > > > -#define KEXEC_UPDATE_FDT       0x00000008
> > > > +#define KEXEC_CRASH_HOTPLUG_UPDATE 0x00000004
> > > >    #define KEXEC_UPDATE_ELFCOREHDR        0x00000004
> > > >    #define KEXEC_ARCH_MASK                0xffff0000
> > > >    /*
> > > > 
> > > > With my understanding, the kexec flag should be indicating the action,
> > > > the mem/cpu hotplug, but not relating to any detail. Imagine later
> > > > another segment need be skipped on one ARCH again, then another flag
> > > > need be added, this sounds not reasonable.
> > > I strongly agree with you. The KEXEC_CRASH_HOTPLUG_UPDATE kexec flag
> > > should be sufficient to inform the kernel that the kexec tool has been
> > > updated
> > > to support CPU/Memory hotplug for the kexec_load system call. Unfortunately,
> > > we cannot use the 0x00000004 kexec flags bit for KEXEC_CRASH_HOTPLUG_UPDATE
> > > at the moment.
> > I am fine with 0x00000008 and a new flag, it has the same effect as
> > #define KEXEC_CRASH_HOTPLUG_UPDATE 0x00000004
> > 
> > I am worried about the header file incompatiblity.
> 
> If we are OK to have KEXEC_CRASH_HOTPLUG_UPDATE 0x00000008 as new bit
> to introduce CPU/Memory hotplug feature for kexec_load syscall, we will not
> have
> compatibility issue.
> 
> Let me write next version for this patch with KEXEC_CRASH_HOTPLUG_UPDATE
> 0x00000008
> as new flag bit and show how it will be handled. I will also share kexec
> code for clarity.

It's great we are in the same page about segments excluding done in arch
function. While It's a little unclear to me why we can't reuse 0x00000004
flag value. Then KEXEC_UPDATE_ELFCOREHDR will only exist in v6.6 kernel,
and that bit won't be used in v6.7 and future version.

Except of the existence in kexec-tools utility for XEN, do you see other
barrier? I would like to know so that one day I can explain
KEXEC_UPDATE_ELFCOREHDR to someone else if asked.


  reply	other threads:[~2023-12-22  0:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-11  8:30 [PATCH v14 0/6] powerpc/crash: Kernel handling of CPU and memory hotplug Sourabh Jain
2023-12-11  8:30 ` Sourabh Jain
2023-12-11  8:30 ` [PATCH v14 1/6] crash: forward memory_notify arg to arch crash hotplug handler Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-11  8:30 ` [PATCH v14 2/6] crash: make CPU and Memory hotplug support reporting flexible Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-14 14:13   ` Baoquan He
2023-12-14 14:13     ` Baoquan He
2023-12-15  5:46     ` Sourabh Jain
2023-12-15  5:46       ` Sourabh Jain
2023-12-11  8:30 ` [PATCH v14 3/6] crash: add a new kexec flag for FDT update Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-15  2:28   ` Baoquan He
2023-12-15  2:28     ` Baoquan He
2023-12-15  6:47     ` Sourabh Jain
2023-12-15  6:47       ` Sourabh Jain
2023-12-16  9:41       ` Baoquan He
2023-12-16  9:41         ` Baoquan He
2023-12-16 18:57         ` Sourabh Jain
2023-12-16 18:57           ` Sourabh Jain
2023-12-17  0:59           ` Baoquan He
2023-12-17  0:59             ` Baoquan He
2023-12-17 15:50             ` Sourabh Jain
2023-12-21  6:06             ` Sourabh Jain
2023-12-21  6:06               ` Sourabh Jain
2023-12-22  0:28               ` Baoquan He [this message]
2023-12-22  0:28                 ` Baoquan He
2023-12-11  8:30 ` [PATCH v14 4/6] powerpc/kexec: turn some static helper functions public Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-11  8:30 ` [PATCH v14 5/6] powerpc: add crash CPU hotplug support Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-19 10:35   ` Hari Bathini
2023-12-19 10:35     ` Hari Bathini
2023-12-11  8:30 ` [PATCH v14 6/6] powerpc: add crash memory " Sourabh Jain
2023-12-11  8:30   ` Sourabh Jain
2023-12-15  1:23   ` Baoquan He
2023-12-15  1:23     ` Baoquan He
2023-12-15  5:59     ` Sourabh Jain
2023-12-15  5:59       ` Sourabh Jain
2023-12-16  3:11       ` Baoquan He
2023-12-16  3:11         ` Baoquan He

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=ZYTYJ6sjdzZwjGpS@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=eric.devolder@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hbathini@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=laurent.dufour@fr.ibm.com \
    --cc=lf32.dev@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen@kernel.org \
    --cc=osalvador@suse.de \
    --cc=sourabhjain@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.org \
    --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 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.