kdump: Add external kdump entry point for s390 stand-alone dump tools

Hello Vivek,

I finished the patches that add the stand-alone dump tools support on top of the recently sent v2 patch series. The following three patches implement the program check idea that we have discussed recently:

[1] kdump: Add new machine_kexec_finish() architecture callback
[2] s390: Add external kdump entry point for s390 stand-alone dump tools
[3] kexec-tools: Emit program check on s390 for checksum failure

Thanks!

Michael

From: Michael Holzheu <[email protected]>

In order to be able to set the "kdump active" flag on s390, this patch adds the new kexec architecture callback "machine_kexec_finish()".

---
 include/linux/kexec.h |    1 +
 kernel/kexec.c        |    8 ++++++++
 2 files changed, 9 insertions(+)

@@ -115,6 +115,7 @@ struct kimage {
 /* kexec interface functions */
 extern void machine_kexec(struct kimage *image);
 extern int machine_kexec_prepare(struct kimage *image);
+extern void machine_kexec_finish(struct kimage *image, int flags);
 extern void machine_kexec_cleanup(struct kimage *image);
 extern asmlinkage long sys_kexec_load(unsigned long entry,
 					unsigned long nr_segments,

@@ -1017,6 +1017,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
 		kimage_terminate(image);
 	}
 	/* Install the new kernel, and  Uninstall the old */
+	machine_kexec_finish(image, flags);
 	image = xchg(dest_image, image);
 
 out:

@@ -1026,6 +1027,13 @@ out:
 	return result;
 }
 
+/*
+ * provide an empty default implementation here -- architecture
+ * code may override this
+ */
+void __weak machine_kexec_finish(struct kimage *image, int flags)
+{}
+
 #ifdef CONFIG_COMPAT
 asmlinkage long compat_sys_kexec_load(unsigned long entry,
 				unsigned long nr_segments,

From: Michael Holzheu <[email protected]>

On s390 we want to be able to trigger kdump via our stand-alone dump tools, if a valid kdump kernel has been pre-loaded. The mechanism works as follows:
We establish a ABI defined kdump entry point in the old kernel at 0x10018 and a "kdump active" flag at 0xe18. The dump tools first verify 0xe18 in order to find out if kdump kernel has been loaded. If kdump is loaded they jump to 0x10008 which then triggers crash_kexec(). The dump tools establish a program check handler so that if crash_kexec() or purgatory is corrupted we return to the dump tools and create a full-blown stand-alone dump as backup mechanism.

---
 arch/s390/include/asm/kexec.h    |    1 
 arch/s390/include/asm/lowcore.h  |    4 +-
 arch/s390/kernel/entry64.S       |   16 ++++++++++
 arch/s390/kernel/head.S          |    8 ++++-
 arch/s390/kernel/head64.S        |    3 +
 arch/s390/kernel/head_kdump.S    |   13 ++++++++
 arch/s390/kernel/ipl.c           |    8 -----
 arch/s390/kernel/machine_kexec.c |   61 +++++++++++++++++++++++++++++++++++++++
 8 files changed, 105 insertions(+), 9 deletions(-)

@@ -40,4 +40,5 @@
 #define KEXEC_ARCH KEXEC_ARCH_S390
 
 extern void crash_setup_regs(struct pt_regs *newregs, struct pt_regs *oldregs);
+extern void s390_kdump_int(void);
 #endif /*_S390_KEXEC_H */

@@ -165,6 +165,7 @@ struct _lowcore {
 
 #define LC_ORDER 1
 #define LC_PAGES 2
+#define LC_KDUMP_ACTIVE_FLAG 0x4b44554d50414354ULL
 
 struct save_area {
 	u64	fp_regs[16];

@@ -295,7 +296,8 @@ struct _lowcore {
 	/* 64 bit save area */
 	__u64	save_area_64;			/* 0x0e0c */
 	__u32	ipib_checksum_perm;		/* 0x0e14 */
-	__u8	pad_0x0e18[0x0f00-0x0e18];	/* 0x0e18 */
+	__u64	kdump_active;			/* 0x0e18 */
+	__u8	pad_0x0e20[0x0f00-0x0e20];	/* 0x0e20 */
 
 	/* Extended facility list */
 	__u64	stfle_fac_list[32];		/* 0x0f00 */

@@ -885,6 +885,22 @@ ENTRY(psw_restart_int_handler)
 restart_psw_crash:
 	.quad	0x0002000080000000,0x0000000000000000 + restart_psw_crash
 
+#
+# kdump external entry (can be called from stand-alone dump tools)
+#
+ENTRY(kdump_ext_handler)
+	stg	%r15,__LC_SAVE_AREA_64(%r0)	# save r15
+	larl	%r15,restart_stack		# load restart stack
+	lg	%r15,0(%r15)
+	aghi	%r15,-SP_SIZE			# make room for pt_regs
+	stmg	%r0,%r14,SP_R0(%r15)		# store gprs %r0-%r14 to stack
+	mvc	SP_R15(8,%r15),__LC_SAVE_AREA_64(%r0)# store saved %r15 to stack
+	xc	__SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15) # set backchain to 0
+
+	brasl	%r14,s390_kdump_ext
+0:	j	0b+2				# Force program check
+#endif
+
 	.section .kprobes.text, "ax"
 
 #ifdef CONFIG_CHECK_STACK

@@ -452,13 +452,19 @@ ENTRY(startup)
 	j	.Lep_startup_normal
 	.org	0x10008
 	.ascii	"S390EP"
-	.byte	0x00,0x01
+	.byte	0x00,0x02
 #
 # kdump startup-code at 0x10010, running in 64 bit absolute addressing mode
 #
 	.org	0x10010
 ENTRY(startup_kdump)
 	j	.Lep_startup_kdump
+#
+# External kdump startup-code at 0x10018
+#
+	.org	0x10018
+ENTRY(startup_kdump_ext)
+	j	.Lep_startup_kdump_ext
 .Lep_startup_normal:
 	basr	%r13,0			# get base
 .LPG0:

@@ -88,6 +88,9 @@ ENTRY(_ehead)
 ENTRY(_stext)
 	basr	%r13,0			# get base
 .LPG3:
+	larl	%r2,kdump_ext_handler		# Set kdump ext handler address
+	larl	%r3,kdump_ext_handler_addr	# This is needed
+	stg	%r2,0(%r3)			# because of bzImage
 # check control registers
 	stctg	%c0,%c15,0(%r15)
 	oi	6(%r15),0x40		# enable sigp emergency signal

@@ -97,8 +97,21 @@ startup_kdump_relocated:
 	.long	0x00080000,0x80000000 + startup
 .Lpgm_psw:
 	.quad	0x0000000180000000,0x0000000000000000 + .Lno_diag308
+
+.align 2
+.Lep_startup_kdump_ext:
+	larl	%r14,kdump_ext_handler_addr
+	lg	%r14,0(%r14)
+	br	%r14
+
+ENTRY(kdump_ext_handler_addr)
+	.quad	0xffffffffffffffff
 #else
 .align 2
+.Lep_startup_kdump_ext:
+	br	%r14
+
+.align 2
 .Lep_startup_kdump:
 #ifdef CONFIG_64BIT
 	larl	%r13,startup_kdump_crash

@@ -1651,13 +1651,7 @@ static int kdump_init(void)
 
 static void kdump_run(struct shutdown_trigger *trigger)
 {
-	pfault_fini();
-	s390_reset_system();
-	__arch_local_irq_stnsm(0xfb); /* disable DAT */
-	store_status();
-
-	crash_kexec(NULL);
-	disabled_wait((unsigned long) __builtin_return_address(0));
+	s390_kdump_int();
 }
 
 static struct shutdown_action kdump_action = {SHUTDOWN_ACTION_KDUMP_STR,

From: Michael Holzheu <[email protected]>

With this patch on s390 a program check interrupt is emitted if purgatory checksums are not valid. This establishes a error handling mechanism where the caller of crash_kexec/purgatory can catch the error by installing a program check handler function. On s390 this will be used by our stand-alone dump tools. The tools first get control and install a program check handler. Then if kdump is pre-loaded, the dump tools jump into the old kernel where crash_kexec->purgatory is executed. If kdump fails on this code path, a program check is emitted and then control is passed back to the stand-alone dump tools that will then create a full-blown dump as backup mechanism.

---
 purgatory/arch/i386/purgatory-x86.c      |    7 +++++++
 purgatory/arch/ia64/purgatory-ia64.c     |    7 +++++++
 purgatory/arch/ppc/purgatory-ppc.c       |    7 +++++++
 purgatory/arch/ppc64/purgatory-ppc64.c   |    7 +++++++
 purgatory/arch/s390/purgatory-s390.c     |   11 +++++++++++
 purgatory/arch/x86_64/purgatory-x86_64.c |    7 +++++++
 purgatory/include/purgatory.h            |    1 +
 purgatory/purgatory.c                    |    4 +---
 8 files changed, 48 insertions(+), 3 deletions(-)

@@ -55,3 +55,10 @@ void post_verification_setup_arch(void)
 	if (panic_kernel)    crashdump_backup_memory();
 	if (jump_back_entry) x86_setup_jump_back_entry();
 }
+
+void sha256_digest_failed(void)
+{
+	for(;;) {
+		/* loop forever */
+	}
+}

@@ -305,3 +305,10 @@ void post_verification_setup_arch(void)
 {
 	/* Nothing for now */
 }
+
+void sha256_digest_failed(void)
+{
+	for(;;) {
+		/* loop forever */
+	}
+}

@@ -44,3 +44,10 @@ void crashdump_backup_memory(void)
 {
 	return;
 }
+
+void sha256_digest_failed(void)
+{
+	for(;;) {
+		/* loop forever */
+	}
+}

@@ -40,3 +40,10 @@ void post_verification_setup_arch(void)
 	if (panic_kernel)
 		crashdump_backup_memory();
 }
+
+void sha256_digest_failed(void)
+{
+	for(;;) {
+		/* loop forever */
+	}
+}

@@ -6,6 +6,12 @@
  * Author(s): Michael Holzheu <[email protected]>
  */
 
+#define EMIT_PGM_CHECK() do {			\
+	asm volatile(			\
+		"0:     j       0b+2\n"	\
+	: :);				\
+} while (0)
+
 unsigned long kdump_psw_addr = 0;
 
 void setup_arch(void)

@@ -15,3 +21,8 @@ void setup_arch(void)
 void post_verification_setup_arch(void)
 {
 }
+
+void sha256_digest_failed(void)
+{
+	EMIT_PGM_CHECK();
+}

@@ -28,3 +28,10 @@ void post_verification_setup_arch(void)
 	if (panic_kernel)    crashdump_backup_memory();
 	if (jump_back_entry) x86_setup_jump_back_entry();
 }
+
+void sha256_digest_failed(void)
+{
+	for(;;) {
+		/* loop forever */
+	}
+}

@@ -6,5 +6,6 @@ void sprintf(char *buffer, const char *f
 void printf(const char *fmt, ...);
 void setup_arch(void);
 void post_verification_setup_arch(void);
+void sha256_digest_failed(void);
 
 #endif /* PURGATORY_H */

@@ -34,9 +34,7 @@ void verify_sha256_digest(void)
 			printf("%hhx ", sha256_digest[i]);
 		}
 		printf("\n");
-		for(;;) {
-			/* loop forever */
-		}
+		sha256_digest_failed();
 	}
 }
 

Hi Michael,

in general I am fine with these patches and happy to merge them although I am a little unclear about the status of the kernel side of things. Please let me know if you would like me to merge the kexec-tools patches now or wait a bit (for an updated version?).

Also, if you could give me any pointers on how to obtain an s390 cross-compiling environment for x86_64 I would be most grateful.

Hello Simon,

That's good news.

I think that we are almost done with the discussion. I will send you my current kexec-tools patches and would be glad, if you could integrate them now.

From Monday I will be two weeks on vacation. If there are additional questions please contact Martin Schwidefsky and Heiko Carstens.

There are debian packages for under:
http://debian.speedblue.org/

Michael

On Fri, Aug 19, 2011 at 02:53:20PM +0200, Michael Holzheu wrote:

[...]

I guess kexec-tools integration will make more sense once kernel patches show up atleast in one maintainer's subtree.

Also in kernel patches, atleast we need to resolve the issue of arch specific kmap(), kunmap() calls so that we don't have to make kimage_load_crash_segment() arch specific.

Thanks
Vivek

Hello Vivek,

The s390 kexec-tools kdump code will inactive as long a kernel shows "Crash kernel" in /proc/iomem. So IMHO there is little risk to integrate the code.

As I told in my last mail we will do this later. So I think there are currently no more open issues, correct?

Michael