kexec jump -v12: kexec jump

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

The features of this patch can be used as a general method to call program in physical mode (paging turning off). This can be used to call BIOS code under Linux.

kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL:

source: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-src_git_kh10.tar.bz2
patches: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-patches_git_kh10.tar.bz2
binary: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec_git_kh10

Usage example of calling some physical mode code and return:

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

The features of this patch can be used as a general method to call program in physical mode (paging turning off). This can be used to call BIOS code under Linux.

kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL:

source: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-src_git_kh10.tar.bz2
patches: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-patches_git_kh10.tar.bz2
binary: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec_git_kh10

Usage example of calling some physical mode code and return:

Hi!

The patch looks mostly ok to me. (Perhaps there's time to split it into smaller chunks?)

You can add Acked-by: Pavel Machek <[email protected]> to it, I guess.

arch/x86/kernel/machine_kexec_32.c int machine_kexec_prepare(struct kimage · line 106

Quoted 7 lines

arch/x86/kernel/machine_kexec_32.c +2 -0

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+     if (nx_enabled)
+             set_pages_nx(image->control_code_page, 1);
 }

, 0 ? (setup and cleanup were same, which is strange).

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 8 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

...because otherwise you silently do nothing?

Review static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 1 line

(quoted diff) +1 -0

+#endif

Pavel

Quoted 9 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 7 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

I will change the comments to reflect the changes to kernel_kexec.

Quoted 11 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which may be called in some extreme environment, such as during panic().

Quoted 13 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

Quoted 3 lines

...because otherwise you silently do nothing?

Quoted 1 line

(quoted diff) +1 -0

+#endif

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will always be 0. So current code is safe. Here, #ifdef is used to resolve the dependency issue. For example, save_processor_state() may be undefined if CONFIG_KEXEC_JUMP is not defined.

Quoted 9 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 7 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

I will change the comments to reflect the changes to kernel_kexec.

Quoted 11 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which may be called in some extreme environment, such as during panic().

Quoted 13 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

Quoted 3 lines

...because otherwise you silently do nothing?

Quoted 1 line

(quoted diff) +1 -0

+#endif

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will always be 0. So current code is safe. Here, #ifdef is used to resolve the dependency issue. For example, save_processor_state() may be undefined if CONFIG_KEXEC_JUMP is not defined.

Hi!

Quoted 42 lines

Quoted 9 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 7 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

I will change the comments to reflect the changes to kernel_kexec.

Quoted 11 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which may be called in some extreme environment, such as during panic().

Quoted 15 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

...because otherwise you silently do nothing?

Quoted 6 lines

Quoted 1 line

Review static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 1 line

(quoted diff) +1 -0

+#endif

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will always be 0. So current code is safe. Here, #ifdef is used to resolve the dependency issue. For example, save_processor_state() may be undefined if CONFIG_KEXEC_JUMP is not defined.

Move the #ifdef outside the if (), then, so this is clear?

Actually, if preserve_context is always zero in !KEXEC_JUMP case, it might make sense to remove whole variable...

Hi!

Quoted 42 lines

Quoted 9 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 7 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

I will change the comments to reflect the changes to kernel_kexec.

Quoted 11 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which may be called in some extreme environment, such as during panic().

Quoted 15 lines

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

...because otherwise you silently do nothing?

Quoted 6 lines

Quoted 1 line

Review static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 1 line

(quoted diff) +1 -0

+#endif

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will always be 0. So current code is safe. Here, #ifdef is used to resolve the dependency issue. For example, save_processor_state() may be undefined if CONFIG_KEXEC_JUMP is not defined.

Move the #ifdef outside the if (), then, so this is clear?

Actually, if preserve_context is always zero in !KEXEC_JUMP case, it might make sense to remove whole variable...

Hi!

The patch looks mostly ok to me. (Perhaps there's time to split it into smaller chunks?)

You can add Acked-by: Pavel Machek <[email protected]> to it, I guess.

arch/x86/kernel/machine_kexec_32.c int machine_kexec_prepare(struct kimage · line 106

Quoted 7 lines

arch/x86/kernel/machine_kexec_32.c +2 -0

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+     if (nx_enabled)
+             set_pages_nx(image->control_code_page, 1);
 }

, 0 ? (setup and cleanup were same, which is strange).

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1426

Quoted 8 lines

kernel/kexec.c +3 -0

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *   kernel_kexec - reboot the system

Really?

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1436

Quoted 9 lines

kernel/kexec.c +9 -0

+ *   Move into place and start executing a preloaded standalone
+ *   executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+     int error = 0;
+
+     if (xchg(&kexec_lock, 1))
+             return -EBUSY;

That's quite a strange way to provide a lock. mutex_trylock?

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 9 lines

kernel/kexec.c +9 -0

+     if (!kexec_image) {
+             error = -EINVAL;
+             goto Unlock;
+     }
+
+     if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+             local_irq_disable();
+             save_processor_state();

#else
        BUG()

...because otherwise you silently do nothing?

Review static int __init crash_save_vmcoreinfo_ · line 1445

Quoted 1 line

(quoted diff) +1 -0

+#endif

Pavel

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

arch/x86/kernel/machine_kexec_32.c +13 -2

@@ -22,6 +22,7 @@
 #include <asm/cpufeature.h>
 #include <asm/desc.h>
 #include <asm/system.h>
+#include <asm/cacheflush.h>
 
 #define PAGE_ALIGNED __attribute__ ((__aligned__(PAGE_SIZE)))
 static u32 kexec_pgd[1024] PAGE_ALIGNED;

@@ -85,10 +86,12 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Make control page executable.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_x(image->control_code_page, 1);
 	return 0;
 }
 

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_nx(image->control_code_page, 1);
 }
 
 /*
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-NORET_TYPE void machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage unsigned long
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae,
+				       unsigned int preserve_context);
 
 	tracer_disable();
 

kernel/kexec.c +31 -0

@@ -24,6 +24,8 @@
 #include <linux/utsrelease.h>
 #include <linux/utsname.h>
 #include <linux/numa.h>
+#include <linux/suspend.h>
+#include <linux/device.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>

@@ -242,6 +244,12 @@ static int kimage_normal_alloc(struct ki
 		goto out;
 	}
 
+	image->swap_page = kimage_alloc_control_pages(image, 0);
+	if (!image->swap_page) {
+		printk(KERN_ERR "Could not allocate swap buffer\n");
+		goto out;
+	}
+
 	result = 0;
  out:
 	if (result == 0)

@@ -986,6 +994,8 @@ asmlinkage long sys_kexec_load(unsigned 
 		if (result)
 			goto out;
 
+		if (flags & KEXEC_PRESERVE_CONTEXT)
+			image->preserve_context = 1;
 		result = machine_kexec_prepare(image);
 		if (result)
 			goto out;

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *	kernel_kexec - reboot the system
+ *
+ *	Move into place and start executing a preloaded standalone
+ *	executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+	int error = 0;
+
+	if (xchg(&kexec_lock, 1))
+		return -EBUSY;
+	if (!kexec_image) {
+		error = -EINVAL;
+		goto Unlock;
+	}
+
+	if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+		local_irq_disable();

arch/x86/kernel/relocate_kernel_32.S +7 -0

@@ -20,11 +20,44 @@
 #define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define PAE_PGD_ATTR (_PAGE_PRESENT)
 
+/* control_page + PAGE_SIZE/2 ~ control_page + PAGE_SIZE * 3/4 are
+ * used to save some data for jumping back
+ */
+#define DATA(offset)		(PAGE_SIZE/2+(offset))
+
+/* Minimal CPU state */
+#define ESP			DATA(0x0)

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

arch/x86/kernel/machine_kexec_32.c +13 -2

@@ -22,6 +22,7 @@
 #include <asm/cpufeature.h>
 #include <asm/desc.h>
 #include <asm/system.h>
+#include <asm/cacheflush.h>
 
 #define PAGE_ALIGNED __attribute__ ((__aligned__(PAGE_SIZE)))
 static u32 kexec_pgd[1024] PAGE_ALIGNED;

@@ -85,10 +86,12 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Make control page executable.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_x(image->control_code_page, 1);
 	return 0;
 }
 

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_nx(image->control_code_page, 1);
 }
 
 /*
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-NORET_TYPE void machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage unsigned long
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae,
+				       unsigned int preserve_context);
 
 	tracer_disable();
 

kernel/kexec.c +31 -0

@@ -24,6 +24,8 @@
 #include <linux/utsrelease.h>
 #include <linux/utsname.h>
 #include <linux/numa.h>
+#include <linux/suspend.h>
+#include <linux/device.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>

@@ -242,6 +244,12 @@ static int kimage_normal_alloc(struct ki
 		goto out;
 	}
 
+	image->swap_page = kimage_alloc_control_pages(image, 0);
+	if (!image->swap_page) {
+		printk(KERN_ERR "Could not allocate swap buffer\n");
+		goto out;
+	}
+
 	result = 0;
  out:
 	if (result == 0)

@@ -986,6 +994,8 @@ asmlinkage long sys_kexec_load(unsigned 
 		if (result)
 			goto out;
 
+		if (flags & KEXEC_PRESERVE_CONTEXT)
+			image->preserve_context = 1;
 		result = machine_kexec_prepare(image);
 		if (result)
 			goto out;

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *	kernel_kexec - reboot the system
+ *
+ *	Move into place and start executing a preloaded standalone
+ *	executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+	int error = 0;
+
+	if (xchg(&kexec_lock, 1))
+		return -EBUSY;
+	if (!kexec_image) {
+		error = -EINVAL;
+		goto Unlock;
+	}
+
+	if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+		local_irq_disable();

arch/x86/kernel/relocate_kernel_32.S +7 -0

@@ -20,11 +20,44 @@
 #define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define PAE_PGD_ATTR (_PAGE_PRESENT)
 
+/* control_page + PAGE_SIZE/2 ~ control_page + PAGE_SIZE * 3/4 are
+ * used to save some data for jumping back
+ */
+#define DATA(offset)		(PAGE_SIZE/2+(offset))
+
+/* Minimal CPU state */
+#define ESP			DATA(0x0)

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Acked-by Vivek Goyal <[email protected]>

Few minor comments inline.

[..]

Quoted 53 lines

arch/x86/kernel/machine_kexec_32.c +13 -2

@@ -22,6 +22,7 @@
 #include <asm/cpufeature.h>
 #include <asm/desc.h>
 #include <asm/system.h>
+#include <asm/cacheflush.h>
 
 #define PAGE_ALIGNED __attribute__ ((__aligned__(PAGE_SIZE)))
 static u32 kexec_pgd[1024] PAGE_ALIGNED;

@@ -85,10 +86,12 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Make control page executable.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_x(image->control_code_page, 1);
 	return 0;
 }
 

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_nx(image->control_code_page, 1);
 }
 
 /*
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-NORET_TYPE void machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage unsigned long
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae,
+				       unsigned int preserve_context);
 
 	tracer_disable();
 

@@ -115,10 +126,11 @@ NORET_TYPE void machine_kexec(struct kim
 	local_irq_disable();
 

arch/x86/kernel/machine_kexec_32.c NORET_TYPE void machine_kexec(struct kim · line 130

Quoted 4 lines

arch/x86/kernel/machine_kexec_32.c +1 -1

 	control_page = page_address(image->control_code_page);
-	memcpy(control_page, relocate_kernel, PAGE_SIZE);
+	memcpy(control_page, relocate_kernel, PAGE_SIZE/2);
 

Is it possible to add either a compile time or run time check somewhere to make sure code in relocate_kernel.S does not exceed PAGE_SIZE/2.

[..]

Quoted 63 lines

kernel/kexec.c +36 -0

@@ -24,6 +24,8 @@
 #include <linux/utsrelease.h>
 #include <linux/utsname.h>
 #include <linux/numa.h>
+#include <linux/suspend.h>
+#include <linux/device.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>

@@ -242,6 +244,12 @@ static int kimage_normal_alloc(struct ki
 		goto out;
 	}
 
+	image->swap_page = kimage_alloc_control_pages(image, 0);
+	if (!image->swap_page) {
+		printk(KERN_ERR "Could not allocate swap buffer\n");
+		goto out;
+	}
+
 	result = 0;
  out:
 	if (result == 0)

@@ -986,6 +994,8 @@ asmlinkage long sys_kexec_load(unsigned 
 		if (result)
 			goto out;
 
+		if (flags & KEXEC_PRESERVE_CONTEXT)
+			image->preserve_context = 1;
 		result = machine_kexec_prepare(image);
 		if (result)
 			goto out;

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *	kernel_kexec - reboot the system
+ *
+ *	Move into place and start executing a preloaded standalone
+ *	executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+	int error = 0;
+
+	if (xchg(&kexec_lock, 1))
+		return -EBUSY;
+	if (!kexec_image) {
+		error = -EINVAL;
+		goto Unlock;
+	}
+
+	if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+		local_irq_disable();
+		save_processor_state();
+#endif
+	} else {
+		blocking_notifier_call_chain(&reboot_notifier_list,
+					     SYS_RESTART, NULL);

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1454

Quoted 5 lines

kernel/kexec.c +5 -0

+		system_state = SYSTEM_RESTART;
+		device_shutdown();
+		sysdev_shutdown();
+		printk(KERN_EMERG "Starting new kernel\n");
+		machine_shutdown();

All the above code was part of kernel_restart_prepare(), can't we just make that function non-static and use that?

[..]

Quoted 21 lines

arch/x86/kernel/relocate_kernel_32.S +15 -0

@@ -20,11 +20,44 @@
 #define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define PAE_PGD_ATTR (_PAGE_PRESENT)
 
+/* control_page + PAGE_SIZE/2 ~ control_page + PAGE_SIZE * 3/4 are
+ * used to save some data for jumping back
+ */
+#define DATA(offset)		(PAGE_SIZE/2+(offset))
+
+/* Minimal CPU state */
+#define ESP			DATA(0x0)
+#define CR0			DATA(0x4)
+#define CR3			DATA(0x8)
+#define CR4			DATA(0xc)
+
+/* other data */
+#define CP_VA_CONTROL_PAGE	DATA(0x10)
+#define CP_PA_PGD		DATA(0x14)
+#define CP_PA_SWAP_PAGE		DATA(0x18)

arch/x86/kernel/relocate_kernel_32.S line 39

Quoted 2 lines

arch/x86/kernel/relocate_kernel_32.S +2 -0

+#define CP_PA_BACKUP_PAGES_MAP	DATA(0x1c)
+

In general, this assembly piece of code is getting bigger and its difficult to read it now. I think we should at-least pull out the page table setup code into C. Somebody had posted a patch to do that. Don't know what happened to that. Anyway, this is a separate issue and is on wish list.

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Acked-by Vivek Goyal <[email protected]>

Few minor comments inline.

[..]

Quoted 53 lines

arch/x86/kernel/machine_kexec_32.c +13 -2

@@ -22,6 +22,7 @@
 #include <asm/cpufeature.h>
 #include <asm/desc.h>
 #include <asm/system.h>
+#include <asm/cacheflush.h>
 
 #define PAGE_ALIGNED __attribute__ ((__aligned__(PAGE_SIZE)))
 static u32 kexec_pgd[1024] PAGE_ALIGNED;

@@ -85,10 +86,12 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Make control page executable.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_x(image->control_code_page, 1);
 	return 0;
 }
 

@@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled)
+		set_pages_nx(image->control_code_page, 1);
 }
 
 /*
  * Do not allocate memory (or fail in any way) in machine_kexec().
  * We are past the point of no return, committed to rebooting now.
  */
-NORET_TYPE void machine_kexec(struct kimage *image)
+void machine_kexec(struct kimage *image)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage unsigned long
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae,
+				       unsigned int preserve_context);
 
 	tracer_disable();
 

@@ -115,10 +126,11 @@ NORET_TYPE void machine_kexec(struct kim
 	local_irq_disable();
 

arch/x86/kernel/machine_kexec_32.c NORET_TYPE void machine_kexec(struct kim · line 130

Quoted 4 lines

arch/x86/kernel/machine_kexec_32.c +1 -1

 	control_page = page_address(image->control_code_page);
-	memcpy(control_page, relocate_kernel, PAGE_SIZE);
+	memcpy(control_page, relocate_kernel, PAGE_SIZE/2);
 

Is it possible to add either a compile time or run time check somewhere to make sure code in relocate_kernel.S does not exceed PAGE_SIZE/2.

[..]

Quoted 63 lines

kernel/kexec.c +36 -0

@@ -24,6 +24,8 @@
 #include <linux/utsrelease.h>
 #include <linux/utsname.h>
 #include <linux/numa.h>
+#include <linux/suspend.h>
+#include <linux/device.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>

@@ -242,6 +244,12 @@ static int kimage_normal_alloc(struct ki
 		goto out;
 	}
 
+	image->swap_page = kimage_alloc_control_pages(image, 0);
+	if (!image->swap_page) {
+		printk(KERN_ERR "Could not allocate swap buffer\n");
+		goto out;
+	}
+
 	result = 0;
  out:
 	if (result == 0)

@@ -986,6 +994,8 @@ asmlinkage long sys_kexec_load(unsigned 
 		if (result)
 			goto out;
 
+		if (flags & KEXEC_PRESERVE_CONTEXT)
+			image->preserve_context = 1;
 		result = machine_kexec_prepare(image);
 		if (result)
 			goto out;

@@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
 }
 
 module_init(crash_save_vmcoreinfo_init)
+
+/**
+ *	kernel_kexec - reboot the system
+ *
+ *	Move into place and start executing a preloaded standalone
+ *	executable.  If nothing was preloaded return an error.
+ */
+int kernel_kexec(void)
+{
+	int error = 0;
+
+	if (xchg(&kexec_lock, 1))
+		return -EBUSY;
+	if (!kexec_image) {
+		error = -EINVAL;
+		goto Unlock;
+	}
+
+	if (kexec_image->preserve_context) {
+#ifdef CONFIG_KEXEC_JUMP
+		local_irq_disable();
+		save_processor_state();
+#endif
+	} else {
+		blocking_notifier_call_chain(&reboot_notifier_list,
+					     SYS_RESTART, NULL);

kernel/kexec.c static int __init crash_save_vmcoreinfo_ · line 1454

Quoted 5 lines

kernel/kexec.c +5 -0

+		system_state = SYSTEM_RESTART;
+		device_shutdown();
+		sysdev_shutdown();
+		printk(KERN_EMERG "Starting new kernel\n");
+		machine_shutdown();

All the above code was part of kernel_restart_prepare(), can't we just make that function non-static and use that?

[..]

Quoted 21 lines

arch/x86/kernel/relocate_kernel_32.S +15 -0

@@ -20,11 +20,44 @@
 #define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define PAE_PGD_ATTR (_PAGE_PRESENT)
 
+/* control_page + PAGE_SIZE/2 ~ control_page + PAGE_SIZE * 3/4 are
+ * used to save some data for jumping back
+ */
+#define DATA(offset)		(PAGE_SIZE/2+(offset))
+
+/* Minimal CPU state */
+#define ESP			DATA(0x0)
+#define CR0			DATA(0x4)
+#define CR3			DATA(0x8)
+#define CR4			DATA(0xc)
+
+/* other data */
+#define CP_VA_CONTROL_PAGE	DATA(0x10)
+#define CP_PA_PGD		DATA(0x14)
+#define CP_PA_SWAP_PAGE		DATA(0x18)

arch/x86/kernel/relocate_kernel_32.S line 39

Quoted 2 lines

arch/x86/kernel/relocate_kernel_32.S +2 -0

+#define CP_PA_BACKUP_PAGES_MAP	DATA(0x1c)
+

In general, this assembly piece of code is getting bigger and its difficult to read it now. I think we should at-least pull out the page table setup code into C. Somebody had posted a patch to do that. Don't know what happened to that. Anyway, this is a separate issue and is on wish list.

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

What are the prospects of supporting other architectures?

Who maintains kexec-tools, and are they OK with merging up the corresponding changes?

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

What are the prospects of supporting other architectures?

Who maintains kexec-tools, and are they OK with merging up the corresponding changes?

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Huang also talks of using this feature for snapshotting kernel and invoking some BIOS code in protected mode. I am not very sure how exactly are they planning to use it. Huang, do you have more details on this?

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Huang also talks of using this feature for snapshotting kernel and invoking some BIOS code in protected mode. I am not very sure how exactly are they planning to use it. Huang, do you have more details on this?

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Quoted 4 lines

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Ah. You mean keeping both kernels in memory at the same time? In the above, I was replacing one image with another.

Quoted 16 lines · Nigel Cunningham

Hi.

Quoted 12 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

Quoted 5 lines

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging.

Quoted 16 lines · Nigel Cunningham

Hi.

Quoted 12 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

Quoted 5 lines

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging.

Quoted 23 lines · Nigel Cunningham

Quoted 21 lines

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Quoted 3 lines

Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging.

What do you mean by supposed to be used on half-broken system?

Quoted 23 lines · Nigel Cunningham

Quoted 21 lines

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Quoted 3 lines

Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging.

What do you mean by supposed to be used on half-broken system?

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able

Quoted 4 lines

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Ah. You mean keeping both kernels in memory at the same time? In the above, I was replacing one image with another.

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able to switch back and forth, and I developed the code because I imagined that it could form part of the foundation for switching between a login screen and users' stored sessions. Is this what you're imagining?

Quoted 4 lines

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Ah. You mean keeping both kernels in memory at the same time? In the above, I was replacing one image with another.

Hi.

Quoted 7 lines · Vivek Goyal

Hi Andrew,

We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here...

Quoted 5 lines

To me this patchset looks interesting for couple of reasons.

- Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time.

I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able to switch back and forth, and I developed the code because I imagined that it could form part of the foundation for switching between a login screen and users' stored sessions. Is this what you're imagining?

Quoted 4 lines

- So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future.

Ah. You mean keeping both kernels in memory at the same time? In the above, I was replacing one image with another.

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

Quoted 20 lines · Andrew Morton

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Quoted 6 lines

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

Well, it will be tricky to get kjump-hibernation right with respect to ACPI, but we should be fairly close to basic hibernation working with this. It has major advantage of not needing refrigerator (and few disadvantages -- like doing aditional boot during suspend).

But main reason I'd like kjump to be in is different -- it should be useful to stuff like "dump but continue running", etc...

The truth is we could do hibernation without the freezer if
(a) some drivers were fixed not to rely on it (kexec doesn't help here),
(b) we had support at the block layer or filesystems level (kexec is a big workaround here).

The truth is we could do hibernation without the freezer if
(a) some drivers were fixed not to rely on it (kexec doesn't help here),
(b) we had support at the block layer or filesystems level (kexec is a big workaround here).

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

Quoted 5 lines · Eric W. Biederman

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

Do you mean "the filesystems depend on the logical RAID device"?

What's to prevent userspace from accessing the physical device directly?

What this amounts to, in the end, is having a way to distinguish the set of I/O requests coming from the hibernation code (reading or writing the memory image) from the set of all other I/O requests. The driver or the block layer has to be set up to allow the first set through while blocking the second set. (And don't forget about the complications caused by error-recovery I/O during the hibernation activity!)

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

Quoted 5 lines · Eric W. Biederman

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

Do you mean "the filesystems depend on the logical RAID device"?

What's to prevent userspace from accessing the physical device directly?

What this amounts to, in the end, is having a way to distinguish the set of I/O requests coming from the hibernation code (reading or writing the memory image) from the set of all other I/O requests. The driver or the block layer has to be set up to allow the first set through while blocking the second set. (And don't forget about the complications caused by error-recovery I/O during the hibernation activity!)

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

Quoted 9 lines · Alan Stern

Quoted 5 lines · Eric W. Biederman

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

Do you mean "the filesystems depend on the logical RAID device"?

Oh yes. Thinko.

Quoted 2 lines

What's to prevent userspace from accessing the physical device directly?

Nothing.

Quoted 7 lines

What this amounts to, in the end, is having a way to distinguish the set of I/O requests coming from the hibernation code (reading or writing the memory image) from the set of all other I/O requests. The driver or the block layer has to be set up to allow the first set through while blocking the second set. (And don't forget about the complications caused by error-recovery I/O during the hibernation activity!)

I guess this problem exists but it is not at all the problem I was thinking of.

Quoted 3 lines

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

The point was something different. The reasons we can not store the state of the system with the hardware devices logically hot unplugged (and thus reuse all of the find device hotplug methods) is because things like the filesystem layer don't know how to cope with their block devices going away an coming back.

That is the problem inserting an virtual software device in the middle can solve. If that works should there be a better way? Certainly but to prove it out starting with a block device wrapper is a trivial way to go.

Quoted 9 lines · Alan Stern

Quoted 5 lines · Eric W. Biederman

I just realized with a little care the block layer does have support for this, or something very close.

You setup a software raid mirror with one disk device. The physical
device can come in and out while the filesystems depend on the real device.

Do you mean "the filesystems depend on the logical RAID device"?

Oh yes. Thinko.

Quoted 2 lines

What's to prevent userspace from accessing the physical device directly?

Nothing.

Quoted 7 lines

What this amounts to, in the end, is having a way to distinguish the set of I/O requests coming from the hibernation code (reading or writing the memory image) from the set of all other I/O requests. The driver or the block layer has to be set up to allow the first set through while blocking the second set. (And don't forget about the complications caused by error-recovery I/O during the hibernation activity!)

I guess this problem exists but it is not at all the problem I was thinking of.

Quoted 3 lines

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

The point was something different. The reasons we can not store the state of the system with the hardware devices logically hot unplugged (and thus reuse all of the find device hotplug methods) is because things like the filesystem layer don't know how to cope with their block devices going away an coming back.

That is the problem inserting an virtual software device in the middle can solve. If that works should there be a better way? Certainly but to prove it out starting with a block device wrapper is a trivial way to go.

Quoted 3 lines

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

The point was something different. The reasons we can not store the state of the system with the hardware devices logically hot unplugged (and thus reuse all of the find device hotplug methods) is because things like the filesystem layer don't know how to cope with their block devices going away an coming back.

That is the problem inserting an virtual software device in the middle can solve. If that works should there be a better way? Certainly but to prove it out starting with a block device wrapper is a trivial way to go.

Quoted 3 lines

Forcing the second set of requests to filter through an extra software layer is a clumsy way of accomplishing this. There ought to be a better approach.

The point was something different. The reasons we can not store the state of the system with the hardware devices logically hot unplugged (and thus reuse all of the find device hotplug methods) is because things like the filesystem layer don't know how to cope with their block devices going away an coming back.

That is the problem inserting an virtual software device in the middle can solve. If that works should there be a better way? Certainly but to prove it out starting with a block device wrapper is a trivial way to go.

Quoted 20 lines · Andrew Morton

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Quoted 6 lines

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

Well, it will be tricky to get kjump-hibernation right with respect to ACPI, but we should be fairly close to basic hibernation working with this. It has major advantage of not needing refrigerator (and few disadvantages -- like doing aditional boot during suspend).

But main reason I'd like kjump to be in is different -- it should be useful to stuff like "dump but continue running", etc...

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

What are the prospects of supporting other architectures?

Who maintains kexec-tools, and are they OK with merging up the corresponding changes?

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

What are the prospects of supporting other architectures?

Who maintains kexec-tools, and are they OK with merging up the corresponding changes?

Quoted 10 lines · On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 8 lines · Huang Ying

This patch provides an enhancement to kexec/kdump. It implements the following features:

- Backup/restore memory used by the original kernel before/after kexec.

- Save/restore CPU state before/after kexec.

Quoted 7 lines

Hi Huang,

In general this patch set looks good enough to live in -mm and get some testing going.

To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality.

Exciting ;) It's much less code than I expected.

I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that?

What are the prospects of supporting other architectures?

Who maintains kexec-tools, and are they OK with merging up the corresponding changes?