On Fri, Sep 19, 2025 at 2:27 PM Stefan Hajnoczi wrote:
>
> On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> >
On Fri, Sep 19, 2025 at 6:14 AM Pasha Tatashin
wrote:
>
> On Thu, Sep 18, 2025 at 6:26 PM Cong Wang wrote:
> >
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> >
From: Cong Wang
Replace static kexec_image and kexec_crash_image globals with a dynamic
linked list infrastructure to support multiple kernel images. This change
enables multikernel functionality while maintaining backward compatibility.
Key changes:
- Add list_head member to kimage structure
From: Cong Wang
Add a dedicated /proc/multikernel file to provide read-only access to
all loaded kernel images in the system.
The interface displays kernel images in a tabular format showing:
- Type: kexec type (default, crash, multikernel)
- Start Address: entry point in hexadecimal format
From: Cong Wang
This patch implements a comprehensive IPI-based communication system
for multikernel environments, enabling data exchange between different
kernel instances running on separate CPUs.
Key features include:
- Generic IPI handler registration and callback mechanism allowing
dedicated kernel instances for specific
workloads etc..
Signed-off-by: Cong Wang
---
Cong Wang (7):
kexec: Introduce multikernel support via kexec
x86: Introduce SMP INIT trampoline for multikernel CPU bootstrap
x86: Introduce MULTIKERNEL_VECTOR for inter-kernel communication
kernel:
From: Cong Wang
The tranditional smp_processor_id() is a software-defined CPU ID which
is only unique within the same kernel. With Multikernel architecture, we
run multiple Linux kernels on different CPU's, hence the host kernel
needs a globally unique CPU ID to manage the CPU's. Th
From: Cong Wang
This patch introduces a dedicated trampoline mechanism for booting
secondary CPUs with different kernel instances in multikernel mode.
The implementation provides:
- New trampoline_64_bsp.S assembly code for real-mode to long-mode
transition when launching kernels on secondary
From: Cong Wang
This patch adds a dedicated IPI vector (0xea) for multikernel
communication, enabling different kernel instances running on
separate CPUs to send interrupts to each other.
The implementation includes:
- MULTIKERNEL_VECTOR definition at interrupt vector 0xea
- IDT entry
From: Cong Wang
This patch extends the kexec subsystem to support multikernel
functionality, allowing different kernel instances to be loaded and
executed on specific CPUs. The implementation introduces:
- New KEXEC_TYPE_MULTIKERNEL type and KEXEC_MULTIKERNEL flag
- multikernel_kick_ap
n-tree.
And those KSTATE_* stuffs look a lot similar to BTF:
https://docs.kernel.org/bpf/btf.html
So, any possibility to reuse BTF here? Note, BTF is automatically
generated by pahole, no manual effort is required.
Regards,
Cong Wang
On Sat, Feb 8, 2025 at 4:14 PM Pasha Tatashin wrote:
>
> On Sat, Feb 8, 2025 at 6:39 PM Cong Wang wrote:
> >
> > Hi Mike,
> >
> > On Thu, Feb 6, 2025 at 5:28 AM Mike Rapoport wrote:
> > >
> > > From: "Mike Rapoport (Microsoft)"
> &
Hi Mike,
On Thu, Feb 6, 2025 at 5:28 AM Mike Rapoport wrote:
> We introduce a metadata file that the kernels pass between each other. How
> they pass it is architecture specific. The file's format is a Flattened
> Device Tree (fdt) which has a generator and parser already included in
> Linux. Whe
Hi Mike,
On Thu, Feb 6, 2025 at 5:28 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (Microsoft)"
>
> Hi,
>
> This a next version of Alex's "kexec: Allow preservation of ftrace buffers"
> series (https://lore.kernel.org/all/20240117144704.602-1-g...@amazon.com),
> just to make things simpler in
inside the loop each time.
Verify the result by comparing the vmcore-dmesg output with and without
this patch.
Cc: Simon Horman
Reviewed-by: Dave Young
Reviewed-by: Pratyush Anand
Signed-off-by: Cong Wang
---
vmcore-dmesg/vmcore-dmesg.c | 99 ++---
1
inside the loop each time.
Verify the result by comparing the vmcore-dmesg output with and without
this patch.
Cc: Simon Horman
Reviewed-by: Dave Young
Reviewed-by: Pratyush Anand
Signed-off-by: Cong Wang
---
vmcore-dmesg/vmcore-dmesg.c | 99 ++---
1
On Tue, Jun 27, 2017 at 10:19 PM, Dave Young wrote:
> On 06/19/17 at 03:23pm, Cong Wang wrote:
>> -
>> - /* Move to next record */
>> - current_idx = log_next(buf, current_idx);
>> + free(msg);
>> + /* length ==
Ping... Any review?
On Mon, Jun 19, 2017 at 3:23 PM, Cong Wang wrote:
> In kdump kernel, we got:
>
> Saving vmcore-dmesg.txt
> Failed to malloc 67108864 bytes for the logbuf: Cannot allocate memory
>
> Apparently 64M is too luxury for a kdump kernel which only has 128M
inside the loop each time.
Verify the result by comparing the vmcore-dmesg output with and without
this patch.
Cc: Simon Horman
Signed-off-by: Cong Wang
---
vmcore-dmesg/vmcore-dmesg.c | 101 ++--
1 file changed, 41 insertions(+), 60 deletions(-)
diff
On Mon, 2012-07-23 at 20:22 +0900, Takao Indoh wrote:
> (2012/07/23 19:00), Dave Young wrote:
> > On 07/17/2012 11:15 AM, Takao Indoh wrote:
> >
> >> Hi Cong,
> >>
> >> When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
> >> kernel's panic in find_early_table_space().
> >>
> >>
On Thu, 07 Jun 2012 at 22:47 GMT, Ben Shelton wrote:
> Hi all,
>
> I'm working on a distributed-computing project where we'd like to boot
> multiple instances of the Linux kernel on the same machine. We'd like to
> leverage kexec to decompress each guest kernel and copy it to an area within
>
On Thu, May 24, 2012 at 8:31 AM, Simon Horman wrote:
> On Wed, May 23, 2012 at 06:20:12PM +0530, Suzuki K. Poulose wrote:
>> It builds and works fine for me on PPC32. Sample output below.
>
> Thanks!
Thanks to both of you! :)
___
kexec mailing list
kex
From: Cong Wang
From: Cong Wang
V2: Fix a compile error
Like commit 28d4ab53280853d2aeefdfb7c369331e89ab9ac2
("Add generic debug option"), this one moves code
under #if DEBUG to --debug on ppc arch.
Sorry that I still can't find a ppc32 machine to test this.
Cc: Simon Horman
On 03/15/2012 02:48 PM, Simon Horman wrote:
On Tue, Mar 13, 2012 at 10:58:40AM +0800, Cong Wang wrote:
On 03/13/2012 08:21 AM, Simon Horman wrote:
On Thu, Mar 08, 2012 at 02:39:38PM +0800, Cong Wang wrote:
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug
On 03/13/2012 08:21 AM, Simon Horman wrote:
On Thu, Mar 08, 2012 at 02:39:38PM +0800, Cong Wang wrote:
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug, we have to re-compile the source
code with -DDEBUG. This is not convenient, we want to have
a generic
On Thu, 08 Mar 2012 at 17:29 GMT, Maxim Kammerer wrote:
> Hi,
>
> In kexec/arch/i386/x86-linux-setup.c:setup_linux_vesafb():
>
> fprintf(stderr, "%s: %dx%dx%d @ %lx +%x\n", __FUNCTION__,
> var.xres, var.yres, var.bits_per_pixel,
> fix.smem_start, fix.smem_len);
>
> This message
--debug to generic place
and moves code under #ifdef DEBUG to --debug on x86.
BTW, the size of kexec binary increases very little after this patch.
Signed-off-by: Cong Wang
---
kexec/arch/i386/crashdump-x86.c | 74 +-
kexec/arch/i386/include/arch/options.h
Like patch 1/5, this one moves code under #if DEBUG to --debug
on ppc arch.
Signed-off-by: Cong Wang
---
kexec/arch/ppc/crashdump-powerpc.c | 18 --
kexec/arch/ppc/fixup_dtb.c | 25 +++--
kexec/arch/ppc/fs2dt.c |6 +++---
kexec
Like patch 1/5, this one moves code under #if DEBUG to --debug
on sh arch.
Signed-off-by: Cong Wang
---
kexec/arch/sh/crashdump-sh.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kexec/arch/sh/crashdump-sh.c b/kexec/arch/sh/crashdump-sh.c
index f3c8c74..68ca756
Like patch 1/5, this one moves code under #if DEBUG to --debug
on mips arch.
Signed-off-by: Cong Wang
---
kexec/arch/mips/crashdump-mips.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
Like patch 1/5, this one moves code under #if DEBUG to --debug
on arm arch.
Signed-off-by: Cong Wang
---
kexec/arch/arm/crashdump-arm.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index e9b22bf
The following functions/variables can become static.
Signed-off-by: WANG Cong
---
diff --git a/kexec/kexec.c b/kexec/kexec.c
index abbe940..89e725e 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -49,7 +49,7 @@
unsigned long long mem_min = 0;
unsigned long long mem_max = ULONG_MAX;
-unsign
On 01/26/2012 01:43 PM, Atsushi Kumagai wrote:
Hi Cong,
By the way, the latest kernel supported by makedumpfile 1.4.2 is still
2.6.36.
makedumpfile.h
383:#define LATEST_VERSION KERNEL_VERSION(2, 6, 36)/* linux-2.6.36
*/
The latest stable kernel is already 3.2.1. :) So, what prev
On 01/26/2012 09:09 AM, Atsushi Kumagai wrote:
Hello Cong,
sourceforge.net had a problem yesterday and I couldn't upload
the newest version. Please refer to the ticket below.
http://sourceforge.net/apps/trac/sourceforge/ticket/23920
The newest version is already uploaded now and I will
announc
On 01/25/2012 06:50 PM, Cong Wang wrote:
Hello, Kumagai-san,
I saw you released 1.4.2:
By the way, the latest kernel supported by makedumpfile 1.4.2 is still
2.6.36.
makedumpfile.h
383:#define LATEST_VERSION KERNEL_VERSION(2, 6, 36)/* linux-2.6.36
*/
The latest stable kernel
Hello, Kumagai-san,
I saw you released 1.4.2:
commit 7ccf93312266eb4b2e4f9ac701875eb926a861f3
Author: Atsushi Kumagai
Date: Mon Jan 23 10:44:07 2012 +0900
[v1.4.2] Update version
This patch updates makedumpfile to version 1.4.2.
Signed-off-by: Atsushi Kumagai
but forgot to p
On 01/20/2012 03:03 PM, Atsushi Kumagai wrote:
Hi,
Hi, Kumagai-san,
I think that makedumpfile should be compiled with -static option,
because it must be executable in many environment as possible, e.g. even if
there are no dynamic libraries in 2nd kernel environment. (as written in README)
B
On Thu, 19 Jan 2012 at 07:46 GMT, Jay Lan wrote:
> Hi,
>
Hi, Jay,
This mailing list is not proper for reporting problems of distro's
mkdumprd, please file a bug in bugzilla of centos.
> I have a 2.6.32-131.6.1.el6 kernel, and kexec-tools-2.0.0-145.el6.x86_64
> rpm on a cent6 machine.
>
> When i
On 01/18/2012 08:40 AM, Ken'ichi Ohmichi wrote:
>
> Hi,
>
> On Wed, 18 Jan 2012 08:35:24 +0800
> Wen Congyang wrote:
>> At 01/18/2012 12:36 AM, Cong Wang Wrote:
>>> Hello, Atsushi,
>>>
>>> I can't build the latest makedumpfil
Hello, Atsushi,
I can't build the latest makedumpfile on Fedora 16,
[wangcong@cr0]~/makedumpfile% make
...
gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -DVERSION='"1.4.1"' -DRELEASE_DATE='"6 January
2012"' -D__x86_64__ print_info.o dwarf_info.o elf_info.o
On Fri, Nov 25, 2011 at 4:19 PM, Dave Young wrote:
> mtd/ram oops dumper will make more functions envolved. In case crash kexec,
> we should avoid kmsg dumper to ensure crashdump success.
>
> kill kmsg_dump callback while crash dumping
https://lkml.org/lkml/2011/2/1/33
__
On Wed, Nov 23, 2011 at 9:18 PM, Michael Holzheu
wrote:
> From: Michael Holzheu
>
> Currently it is possible to set the crash_size via the sysfs
> /sys/kernel/kexec_crash_size even if no crash kernel memory has
> been defined with the "crashkernel" parameter. In this case
> "crashk_res" is not in
Vivek, could you please review this patchset?
Thanks.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
a) rpmbuild doesn't like '-' in version, replace it with '.'.
b) update the files installed in kexec-tools.spec
Signed-off-by: WANG Cong
---
diff --git a/configure.ac b/configure.ac
index 7dd6028..4388bb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,7 @@ dnl
dnl
dnl ---Required
-
On Fri, Nov 18, 2011 at 10:11 AM, Simon Horman wrote:
> On Wed, Nov 16, 2011 at 09:09:26PM +0800, WANG Cong wrote:
>> a) We don't need 'crash_notes' array at all, save some bytes on stack.
>> b) We forgot to fclose 'fp' before return.
>>
>> Signed-off-by: WANG Cong
>>
>> ---
>> diff --git a/kexec
于 2011年04月29日 06:05, Simon Horman 写道:
On Thu, Apr 28, 2011 at 09:15:39AM -0400, Vivek Goyal wrote:
On Thu, Apr 28, 2011 at 03:57:48PM +0800, Cong Wang wrote:
于 2011年04月27日 23:01, Vivek Goyal 写道:
Amerigo,
Now who will do following initialization for ppc?
info->backup_src_st
于 2011年04月20日 00:53, Vivek Goyal 写道:
On Wed, Apr 20, 2011 at 12:20:13AM +0800, Cong Wang wrote:
于 2011年04月19日 20:47, Cong Wang 写道:
于 2011年04月18日 20:58, Vivek Goyal 写道:
Have you verified the contents of backup area? I want to make sure that
everything is working and in second kernel when we
于 2011年04月19日 20:47, Cong Wang 写道:
于 2011年04月18日 20:58, Vivek Goyal 写道:
Have you verified the contents of backup area? I want to make sure that
everything is working and in second kernel when we read up vmcore, we
do read contents properly.
Not yet, I am still trying to figure out what the
于 2011年04月18日 20:58, Vivek Goyal 写道:
On Sun, Apr 17, 2011 at 04:29:05PM +0800, Amerigo Wang wrote:
Vivek pointed out that I missed the i386 part in this commit,
commit 1100580b05e3fdfe648d9be8617d962b11f4b88b
Author: Amerigo Wang
Date: Thu Mar 3 00:10:43 2011 +0800
于 2011年01月09日 10:09, Eric W. Biederman 写道:
We aren't dealing with modules I think CAP_SYS_MODULE is totally
irrelevant in the context of kexec.
Yeah, although I don't really understand CAP_SYS_MODULE, but it
really confused me to add it to kexec_load() from its name.
I think to accomplish
(Forgot Cc'ing Eric Paris, adding.)
Eric pointed out that kexec_load() actually allows you to
run any code you want in ring0, this is more like CAP_SYS_MODULE.
Reported-by: Eric Paris
Signed-off-by: WANG Cong
---
diff --git a/kernel/kexec.c b/kernel/kexec.c
index b55045b..c30d613 100644
--- a/
Eric W. Biederman wrote:
Vivek Goyal writes:
Vitaly, have you really run into cases where 2G upper limit is a concern.
What is the configuration you have, how much memory it has and how much
memory are you planning to reserve for kdump kernel?
A good question.
We have observed that on a m
52 matches
Mail list logo
