kexec based hibernation -v7 : kexec jump

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

Hi!

Quoted 34 lines

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Quoted 1 line

Signed-off-by Huang Ying <[email protected]>

I'm not kexec hacker... but maybe this is in good enough state to be merged? It is useful on its own: kexec jump and back means we can dump system then continue running, for example...

Quoted 3 lines

I'm not kexec hacker... but maybe this is in good enough state to be merged? It is useful on its own: kexec jump and back means we can dump system then continue running, for example...

As far as I'm concerned, patches [1/4] and [2/4] can go.

The other two are not in that shape yet (especially the [3/4] patch).

Quoted 3 lines

I'm not kexec hacker... but maybe this is in good enough state to be merged? It is useful on its own: kexec jump and back means we can dump system then continue running, for example...

As far as I'm concerned, patches [1/4] and [2/4] can go.

The other two are not in that shape yet (especially the [3/4] patch).

Hi!

Quoted 34 lines

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Quoted 1 line

Signed-off-by Huang Ying <[email protected]>

I'm not kexec hacker... but maybe this is in good enough state to be merged? It is useful on its own: kexec jump and back means we can dump system then continue running, for example...

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S      |  214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);
 }
 
 /*
  * 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)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S      |  214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);
 }
 
 /*
  * 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)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,

Quoted 3 lines · Ying

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

Hi,

I am just going through your patches and trying to understand it. Don't understand many things. Asking is easy so here you go...

Quoted 8 lines

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

I need jumping back to restore a already hibernated kernel image? Can you please tell little more about jumping back and why it is needed?

Quoted 9 lines

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

Ok, so due to swapping of source and destination pages first kernel's data is still preserved. How do I get the dynamic memory required for second kernel boot (without writing first kernel's data)?

Quoted 91 lines

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S      |  214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);
 }
 
 /*
  * 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)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae) ATTRIB_NORET;
 
 	/* Interrupts aren't acceptable while we reboot */
 	local_irq_disable();
 

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

Quoted 5 lines

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

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

Is 2K sufficient for all the code in relocate_kernel_32.S? What's the current size?

Quoted 4 lines

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

+	if (image->preserve_cpu) {
+		unsigned int i;
+		KCALL_MAGIC(control_page) = KCALL_MAGIC_NUMBER;
+		KCALL_ARGC(control_page) = argc;

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

Quoted 6 lines

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

+		for (i = 0; i < argc; i++)
+			KCALL_ARGS(control_page)[i] = \
+				va_arg(args, unsigned long);
+
+		if (kexec_call_save_cpu(control_page)) {
+			image->start = KCALL_ENTRY(control_page);

Who fills the entry point at offset 0x200?

[..]

arch/x86/kernel/machine_kexec_32.c

Quoted 8 lines

extern int machine_kexec_prepare(struct kimage *image); extern void machine_kexec_cleanup(struct kimage *image); extern asmlinkage long sys_kexec_load(unsigned long entry,

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

 					unsigned long nr_segments,
 					struct kexec_segment __user *segments,
 					unsigned long flags);
+extern int kexec_call(struct kimage *image, unsigned long *ret,
+		      unsigned int argc, ...);

Who is using kexec_call(). I can't seem to locate the caller of it.

Quoted 3 lines · Ying

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

Hi,

I am just going through your patches and trying to understand it. Don't understand many things. Asking is easy so here you go...

Quoted 8 lines

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

I need jumping back to restore a already hibernated kernel image? Can you please tell little more about jumping back and why it is needed?

Quoted 9 lines

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

Ok, so due to swapping of source and destination pages first kernel's data is still preserved. How do I get the dynamic memory required for second kernel boot (without writing first kernel's data)?

Quoted 91 lines

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S      |  214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);
 }
 
 /*
  * 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)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {
 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae) ATTRIB_NORET;
 
 	/* Interrupts aren't acceptable while we reboot */
 	local_irq_disable();
 

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

Quoted 5 lines

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

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

Is 2K sufficient for all the code in relocate_kernel_32.S? What's the current size?

Quoted 4 lines

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

+	if (image->preserve_cpu) {
+		unsigned int i;
+		KCALL_MAGIC(control_page) = KCALL_MAGIC_NUMBER;
+		KCALL_ARGC(control_page) = argc;

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

Quoted 6 lines

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

+		for (i = 0; i < argc; i++)
+			KCALL_ARGS(control_page)[i] = \
+				va_arg(args, unsigned long);
+
+		if (kexec_call_save_cpu(control_page)) {
+			image->start = KCALL_ENTRY(control_page);

Who fills the entry point at offset 0x200?

[..]

arch/x86/kernel/machine_kexec_32.c

Quoted 8 lines

extern int machine_kexec_prepare(struct kimage *image); extern void machine_kexec_cleanup(struct kimage *image); extern asmlinkage long sys_kexec_load(unsigned long entry,

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

 					unsigned long nr_segments,
 					struct kexec_segment __user *segments,
 					unsigned long flags);
+extern int kexec_call(struct kimage *image, unsigned long *ret,
+		      unsigned int argc, ...);

Who is using kexec_call(). I can't seem to locate the caller of it.

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

[..]

include/linux/kexec.h unsigned long paddr_vmcoreinfo_note(void · line 185

Quoted 9 lines

include/linux/kexec.h +6 -2

-#define KEXEC_ON_CRASH  0x00000001
-#define KEXEC_ARCH_MASK 0xffff0000
+#define KEXEC_ON_CRASH		0x00000001
+#define KEXEC_PRESERVE_CPU	0x00000002
+#define KEXEC_PRESERVE_CPU_EXT	0x00000004
+#define KEXEC_SINGLE_CPU	0x00000008
+#define KEXEC_PRESERVE_DEVICE	0x00000010
+#define KEXEC_PRESERVE_CONSOLE	0x00000020

Hi,

Why do we need so many different flags for preserving different types of state (CPU, CPU_EXT, Device, console) ? To keep things simple, can't we can create just one flag KEXEC_PRESERVE_CONTEXT, which will indicate any special action required for preserving the previous kernel's context so that one can swith back to old kernel?

[..]

include/linux/kexec.h unsigned long paddr_vmcoreinfo_note(void · line 185

Quoted 9 lines

include/linux/kexec.h +6 -2

-#define KEXEC_ON_CRASH  0x00000001
-#define KEXEC_ARCH_MASK 0xffff0000
+#define KEXEC_ON_CRASH		0x00000001
+#define KEXEC_PRESERVE_CPU	0x00000002
+#define KEXEC_PRESERVE_CPU_EXT	0x00000004
+#define KEXEC_SINGLE_CPU	0x00000008
+#define KEXEC_PRESERVE_DEVICE	0x00000010
+#define KEXEC_PRESERVE_CONSOLE	0x00000020

Hi,

Why do we need so many different flags for preserving different types of state (CPU, CPU_EXT, Device, console) ? To keep things simple, can't we can create just one flag KEXEC_PRESERVE_CONTEXT, which will indicate any special action required for preserving the previous kernel's context so that one can swith back to old kernel?

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S | 214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+ change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);

arch/x86/kernel/machine_kexec_32.c +36 -17

 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae) ATTRIB_NORET;
 
 	/* Interrupts aren't acceptable while we reboot */
 	local_irq_disable();
 
 	control_page = page_address(image->control_code_page);
-	memcpy(control_page, relocate_kernel, PAGE_SIZE);
+	memcpy(control_page, relocate_page, PAGE_SIZE/2);
+	KCALL_MAGIC(control_page) = 0;
 
+	if (image->preserve_cpu) {
+		unsigned int i;
+		KCALL_MAGIC(control_page) = KCALL_MAGIC_NUMBER;
+		KCALL_ARGC(control_page) = argc;
+		for (i = 0; i < argc; i++)
+			KCALL_ARGS(control_page)[i] = \
+				va_arg(args, unsigned long);
+
+		if (kexec_call_save_cpu(control_page)) {
+			image->start = KCALL_ENTRY(control_page);
+			if (ret)
+				*ret = KCALL_ARGS(control_page)[0];
+			return 0;
+		}
+	}
+
+	relocate_kernel_ptr = control_page +
+		((void *)relocate_kernel - (void *)relocate_page);
 	page_list[PA_CONTROL_PAGE] = __pa(control_page);
-	page_list[VA_CONTROL_PAGE] = (unsigned long)relocate_kernel;
+	page_list[VA_CONTROL_PAGE] = (unsigned long)control_page;
 	page_list[PA_PGD] = __pa(kexec_pgd);
 	page_list[VA_PGD] = (unsigned long)kexec_pgd;
 #ifdef CONFIG_X86_PAE

@@ -127,26 +166,33 @@ NORET_TYPE void machine_kexec(struct kim
 	page_list[VA_PTE_0] = (unsigned long)kexec_pte0;
 	page_list[PA_PTE_1] = __pa(kexec_pte1);
 	page_list[VA_PTE_1] = (unsigned long)kexec_pte1;
+ page_list[PA_SWAP_PAGE] = (page_to_pfn(image->swap_page) << PAGE_SHIFT);
 
-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the

This patch implements the functionality of jumping between the kexeced kernel and the original kernel.

To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function.

To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too.

A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode.

A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing.

The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/i386/jump_back_protocol.txt |  103 ++++++++++++++
 arch/powerpc/kernel/machine_kexec.c       |    2 
 arch/ppc/kernel/machine_kexec.c           |    2 
 arch/sh/kernel/machine_kexec.c            |    2 
 arch/x86/kernel/machine_kexec_32.c        |   88 +++++++++---
 arch/x86/kernel/machine_kexec_64.c        |    2 
 arch/x86/kernel/relocate_kernel_32.S | 214 +++++++++++++++++++++++++++---
 include/asm-x86/kexec_32.h                |   39 ++++-
 include/linux/kexec.h                     |   40 +++++
 kernel/kexec.c                            |  188 ++++++++++++++++++++++++++
 kernel/power/Kconfig                      |    2 
 kernel/sys.c                              |   35 +++-
 12 files changed, 648 insertions(+), 69 deletions(-)

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

@@ -20,6 +20,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;

@@ -83,10 +84,14 @@ static void load_segments(void)
  * reboot code buffer to allow us to avoid allocations
  * later.
  *
- * Currently nothing.
+ * Turn off NX bit for control page.
  */
 int machine_kexec_prepare(struct kimage *image)
 {
+	if (nx_enabled) {
+ change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC);
+		global_flush_tlb();
+	}
 	return 0;
 }
 

@@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage 
  */
 void machine_kexec_cleanup(struct kimage *image)
 {
+	if (nx_enabled) {
+		change_page_attr(image->control_code_page, 1, PAGE_KERNEL);
+		global_flush_tlb();
+	}
+}
+
+void machine_kexec(struct kimage *image)
+{
+	machine_kexec_call(image, NULL, 0);

arch/x86/kernel/machine_kexec_32.c +36 -17

 	unsigned long page_list[PAGES_NR];
 	void *control_page;
+	asmlinkage NORET_TYPE void
+		(*relocate_kernel_ptr)(unsigned long indirection_page,
+				       unsigned long control_page,
+				       unsigned long start_address,
+				       unsigned int has_pae) ATTRIB_NORET;
 
 	/* Interrupts aren't acceptable while we reboot */
 	local_irq_disable();
 
 	control_page = page_address(image->control_code_page);
-	memcpy(control_page, relocate_kernel, PAGE_SIZE);
+	memcpy(control_page, relocate_page, PAGE_SIZE/2);
+	KCALL_MAGIC(control_page) = 0;
 
+	if (image->preserve_cpu) {
+		unsigned int i;
+		KCALL_MAGIC(control_page) = KCALL_MAGIC_NUMBER;
+		KCALL_ARGC(control_page) = argc;
+		for (i = 0; i < argc; i++)
+			KCALL_ARGS(control_page)[i] = \
+				va_arg(args, unsigned long);
+
+		if (kexec_call_save_cpu(control_page)) {
+			image->start = KCALL_ENTRY(control_page);
+			if (ret)
+				*ret = KCALL_ARGS(control_page)[0];
+			return 0;
+		}
+	}
+
+	relocate_kernel_ptr = control_page +
+		((void *)relocate_kernel - (void *)relocate_page);
 	page_list[PA_CONTROL_PAGE] = __pa(control_page);
-	page_list[VA_CONTROL_PAGE] = (unsigned long)relocate_kernel;
+	page_list[VA_CONTROL_PAGE] = (unsigned long)control_page;
 	page_list[PA_PGD] = __pa(kexec_pgd);
 	page_list[VA_PGD] = (unsigned long)kexec_pgd;
 #ifdef CONFIG_X86_PAE

@@ -127,26 +166,33 @@ NORET_TYPE void machine_kexec(struct kim
 	page_list[VA_PTE_0] = (unsigned long)kexec_pte0;
 	page_list[PA_PTE_1] = __pa(kexec_pte1);
 	page_list[VA_PTE_1] = (unsigned long)kexec_pte1;
+ page_list[PA_SWAP_PAGE] = (page_to_pfn(image->swap_page) << PAGE_SHIFT);
 
-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the

"Huang, Ying" <[email protected]> writes:

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Another usage model may be useful is invoking the kexec image (such as firmware) from kernel space.

- kmalloc the needed memory and loaded the firmware image (if needed)
- sys_kexec_load() with a fake image (one segment with size 0), the entry point of the fake image is the entry point of the firmware image.
- kexec_call(fake_image, ...) /* maybe change entry point if needed */

This way, some kernel code can invoke the firmware in physical mode just like invoking an ordinary function.

[...]

Quoted 30 lines

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

Quoted 8 lines

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

The original idea about this code is:

If the kexec image is claimed that it need not to "perserving extensive CPU state" (such as FPU/MMX/GDT/LDT/IDT/CS/DS/ES/FS/GS/SS etc), the IDT/GDT/CS/DS/ES/FS/GS/SS are not touched in kexec image code. So the segment registers need not to be set.

But this is not clear. At least more description should be provided for each preserve flag.

Quoted 10 lines

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.

You mean I should change the function pointer name to rnk to keep consistency? I find rnk in IA64 implementation.

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Another usage model may be useful is invoking the kexec image (such as firmware) from kernel space.

- kmalloc the needed memory and loaded the firmware image (if needed)
- sys_kexec_load() with a fake image (one segment with size 0), the entry point of the fake image is the entry point of the firmware image.
- kexec_call(fake_image, ...) /* maybe change entry point if needed */

This way, some kernel code can invoke the firmware in physical mode just like invoking an ordinary function.

[...]

Quoted 30 lines

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

Quoted 8 lines

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

The original idea about this code is:

If the kexec image is claimed that it need not to "perserving extensive CPU state" (such as FPU/MMX/GDT/LDT/IDT/CS/DS/ES/FS/GS/SS etc), the IDT/GDT/CS/DS/ES/FS/GS/SS are not touched in kexec image code. So the segment registers need not to be set.

But this is not clear. At least more description should be provided for each preserve flag.

Quoted 10 lines

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.

You mean I should change the function pointer name to rnk to keep consistency? I find rnk in IA64 implementation.

Quoted 32 lines · Ying

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

Quoted 8 lines

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Interesting. We wind up preserving the code in between invocations.

I don't know about your particular issue, but I can see that clearly we need a way to read values back from our target image.

And if we can read everything back one way to proceed is to read everything out modify it and then write it back.

Amending a kexec image that is already stored may also make sense.

I'm not convinced that the var arg parameters make sense, but you added them because of a real need.

The kexec function is split into two separate calls so that we can unmount the filesystem the kexec image comes from before actually doing the kexec.

If extensive user space shutdown or startup is needed I will argue that doing the work in the sys_reboot call is the wrong place to do it. Although if a jump back is happening we should not need much restart.

Can you generate a minimal patch with just the minimal necessary support to return from a kexec operation?

Quoted 10 lines

Another usage model may be useful is invoking the kexec image (such as firmware) from kernel space.

- kmalloc the needed memory and loaded the firmware image (if needed)
- sys_kexec_load() with a fake image (one segment with size 0), the entry point of the fake image is the entry point of the firmware image.
- kexec_call(fake_image, ...) /* maybe change entry point if needed */

This way, some kernel code can invoke the firmware in physical mode just like invoking an ordinary function.

That certainly seems interesting. But that doesn't justify the vararg part of this.

Quoted 42 lines

[...]

Quoted 30 lines

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

Quoted 8 lines

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

The original idea about this code is:

Quoted 7 lines

If the kexec image is claimed that it need not to "perserving extensive CPU state" (such as FPU/MMX/GDT/LDT/IDT/CS/DS/ES/FS/GS/SS etc), the IDT/GDT/CS/DS/ES/FS/GS/SS are not touched in kexec image code. So the segment registers need not to be set.

But this is not clear. At least more description should be provided for each preserve flag.

yes.

Quoted 11 lines

Quoted 10 lines

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.

Quoted 2 lines

You mean I should change the function pointer name to rnk to keep consistency? I find rnk in IA64 implementation.

You were changing something that used to be a pointer back to a pointer
and I found that confusing. See the last one or two commits to
machine_kexec_32.c for when this happened.

I get the feeling that we
need to put the page table creation logic into machine_kexec_prepare, instead of in assembly.

Quoted 32 lines · Ying

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

Quoted 8 lines

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Interesting. We wind up preserving the code in between invocations.

I don't know about your particular issue, but I can see that clearly we need a way to read values back from our target image.

And if we can read everything back one way to proceed is to read everything out modify it and then write it back.

Amending a kexec image that is already stored may also make sense.

I'm not convinced that the var arg parameters make sense, but you added them because of a real need.

The kexec function is split into two separate calls so that we can unmount the filesystem the kexec image comes from before actually doing the kexec.

If extensive user space shutdown or startup is needed I will argue that doing the work in the sys_reboot call is the wrong place to do it. Although if a jump back is happening we should not need much restart.

Can you generate a minimal patch with just the minimal necessary support to return from a kexec operation?

Quoted 10 lines

Another usage model may be useful is invoking the kexec image (such as firmware) from kernel space.

- kmalloc the needed memory and loaded the firmware image (if needed)
- sys_kexec_load() with a fake image (one segment with size 0), the entry point of the fake image is the entry point of the firmware image.
- kexec_call(fake_image, ...) /* maybe change entry point if needed */

This way, some kernel code can invoke the firmware in physical mode just like invoking an ordinary function.

That certainly seems interesting. But that doesn't justify the vararg part of this.

Quoted 42 lines

[...]

Quoted 30 lines

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

Quoted 8 lines

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

The original idea about this code is:

Quoted 7 lines

If the kexec image is claimed that it need not to "perserving extensive CPU state" (such as FPU/MMX/GDT/LDT/IDT/CS/DS/ES/FS/GS/SS etc), the IDT/GDT/CS/DS/ES/FS/GS/SS are not touched in kexec image code. So the segment registers need not to be set.

But this is not clear. At least more description should be provided for each preserve flag.

yes.

Quoted 11 lines

Quoted 10 lines

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.

Quoted 2 lines

You mean I should change the function pointer name to rnk to keep consistency? I find rnk in IA64 implementation.

You were changing something that used to be a pointer back to a pointer
and I found that confusing. See the last one or two commits to
machine_kexec_32.c for when this happened.

I get the feeling that we
need to put the page table creation logic into machine_kexec_prepare, instead of in assembly.

Quoted 32 lines · Ying

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

Quoted 8 lines

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Interesting. We wind up preserving the code in between invocations.

I don't know about your particular issue, but I can see that clearly we need a way to read values back from our target image.

And if we can read everything back one way to proceed is to read everything out modify it and then write it back.

Amending a kexec image that is already stored may also make sense.

I'm not convinced that the var arg parameters make sense, but you added them because of a real need.

The kexec function is split into two separate calls so that we can unmount the filesystem the kexec image comes from before actually doing the kexec.

Quoted 32 lines · Ying

Quoted 1 line · Eric W. Biederman

"Huang, Ying" <[email protected]> writes:

[...]

Quoted 11 lines

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

If all parameters are provided in user space, the usage model may be as follow:

- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with parameters(B)*/
- /* jump back */

That is, the kexec image should be re-loaded if the parameters are different, and there can be no state reserved in kexec image. This is OK for original kexec implementation, because there is no jumping back. But, for kexec with jumping back, another usage model may be useful too.

Quoted 8 lines

- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical mode code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical mode code with parameters(B)*/

This way the kexec image need not to be re-loaded, and the state of kexec image can be reserved across several invoking.

Interesting. We wind up preserving the code in between invocations.

I don't know about your particular issue, but I can see that clearly we need a way to read values back from our target image.

And if we can read everything back one way to proceed is to read everything out modify it and then write it back.

Amending a kexec image that is already stored may also make sense.

I'm not convinced that the var arg parameters make sense, but you added them because of a real need.

The kexec function is split into two separate calls so that we can unmount the filesystem the kexec image comes from before actually doing the kexec.

"Huang, Ying" <[email protected]> writes:

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

Quoted 8 lines

/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now. */

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

-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+			 unsigned int argc, va_list args)
 {

Why do we need var arg support?
Can't we do that with a shim we load from user space?

Quoted 30 lines

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

-	/* The segment registers are funny things, they have both a
-	 * visible and an invisible part.  Whenever the visible part is
-	 * set to a specific selector, the invisible part is loaded
-	 * with from a table in memory.  At no other time is the
-	 * descriptor table in memory accessed.
-	 *
-	 * I take advantage of this here by force loading the
-	 * segments, before I zap the gdt with an invalid value.
-	 */
-	load_segments();
-	/* The gdt & idt are now invalid.
-	 * If you want to load them you must set up your own idt & gdt.
-	 */
-	set_gdt(phys_to_virt(0),0);
-	set_idt(phys_to_virt(0),0);
+	if (image->preserve_cpu_ext) {
+		/* The segment registers are funny things, they have
+		 * both a visible and an invisible part.  Whenever the
+		 * visible part is set to a specific selector, the
+		 * invisible part is loaded with from a table in
+		 * memory.  At no other time is the descriptor table
+		 * in memory accessed.
+		 *
+		 * I take advantage of this here by force loading the
+		 * segments, before I zap the gdt with an invalid
+		 * value.
+		 */
+		load_segments();
+		/* The gdt & idt are now invalid.  If you want to load
+		 * them you must set up your own idt & gdt.

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

Quoted 4 lines

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

+		 */
+		set_gdt(phys_to_virt(0), 0);
+		set_idt(phys_to_virt(0), 0);
+	}

We can't keep the same idt and gdt as the pages they are on will be overwritten/reused. So explictily stomping on them sounds better so they never work. We can restore them on kernel reentry.

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

Quoted 6 lines

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

 	/* now call it */
-	relocate_kernel((unsigned long)image->head, (unsigned long)page_list,
-			image->start, cpu_has_pae);
+	relocate_kernel_ptr((unsigned long)image->head,
+			    (unsigned long)page_list,
+			    image->start, cpu_has_pae);

Why rename relocate_kernel?
Ah. I see. You need to make it into a pointer again. The crazy don't stop the pgd support strikes again. It used to be named rnk.