All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: kexec@lists.infradead.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: incorrect layout of globals from head_64.S during kexec boot
Date: Thu, 5 Jul 2012 23:06:07 +0200	[thread overview]
Message-ID: <20120705210607.GA26908@aepfle.de> (raw)


During kexec in a Xen PVonHVM guest the new kernel crashes most of the
time in secondary_startup_64 because the content of phys_base is
corrupted. Its not zero as expected but has some random other values.
While debugging that crash I came up with the change below to inspect
the memory around phys_base. 

It turned out that the globales are not in the expected memory location.
An expected value such as phys_base_plus1 is shifted, but by a different
amount during repeated kexec attempts. Up to now I havent figured out
where this happens.

My question is: were to put additional debug to trace the copying of the
data section to its final destination? Is this a task of kexec -l or
does that happen during decompressing? I suspect the latter. This is the
console output before the crash (the crash happens in 'movq %rax, %cr3'):

...
[   44.072548] Starting new kernel
I'm in purgatory
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
...


example xenctx output:
rip: 0000000001000146
flags: 00010086 rf s nz p
rsp: 0000000002119c80
rax: 888888888a495999   rcx: 00000000000003d5   rdx: 0000000001000000
rbx: 0000000001cac000   rsi: 0000000000003000   rdi: 0000000001c13000
rbp: 0000000000000000    r8: 0000000001c13000    r9: 1111111111112222
r10: 0000000000001111   r11: 9999999999990000   r12: 8888888888889999
r13: 7777777777778888   r14: 0000000000007777   r15: 0000000000000000
 cs: 0010        ss: 0000        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ 0000000000000000/0000000000000000

cr0: 80000011
cr2: ffffffffff600400
cr3: 0211a000
cr4: 000000a0

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: ffff0ff0
dr7: 00000400
Code (instr addr 01000146)
a0 00 00 00 0f 22 e0 48 c7 c0 00 c0 c0 01 48 03 05 02 3f c1 00 <0f> 22 d8 48 c7 c0 52 01 00 81 ff



diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 94bf9cc..999807c 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -69,6 +69,22 @@ startup_64:
 	/* Compute the delta between the address I am compiled to run at and the
 	 * address I am actually running at.
 	 */
+#if 1
+	movq	$phys_base - __START_KERNEL_map, %rdx
+	movq	phys_base_minus5(%rip),%rbp
+	movq	phys_base_minus4(%rip),%r8
+	movq	phys_base_minus3(%rip),%r9
+	movq	phys_base_minus2(%rip),%r10
+	movq	phys_base_minus1(%rip),%r11
+	movq	phys_base(%rip),%r12
+	movq	phys_base_plus1(%rip),%r13
+	movq	phys_base_plus2(%rip),%r14
+	movq	phys_base_plus3(%rip),%r15
+#if 0
+	ud2a
+	hlt
+#endif
+#endif
 	leaq	_text(%rip), %rbp
 	subq	$_text - __START_KERNEL_map, %rbp
 
@@ -166,6 +182,10 @@ ENTRY(secondary_startup_64)
 	/* Setup early boot stage 4 level pagetables. */
 	movq	$(init_level4_pgt - __START_KERNEL_map), %rax
 	addq	phys_base(%rip), %rax
+#if 0
+	ud2a
+	hlt
+#endif
 	movq	%rax, %cr3
 
 	/* Ensure I am executing from virtual addresses */
@@ -439,10 +459,28 @@ early_gdt_descr:
 	.word	GDT_ENTRIES*8-1
 early_gdt_descr_base:
 	.quad	INIT_PER_CPU_VAR(gdt_page)
-
-ENTRY(phys_base)
+	.align 32
+phys_base_minus5:
+	.quad	0x5555555555555555
+phys_base_minus4:
+	.quad	0x4444444444444444
+phys_base_minus3:
+	.quad	0x3333333333333333
+phys_base_minus2:
+	.quad	0x2222222222222222
+phys_base_minus1:
+	.quad	0x1111111111111111
+
+	.globl phys_base
+phys_base:
 	/* This must match the first entry in level2_kernel_pgt */
 	.quad   0x0000000000000000
+phys_base_plus1:
+	.quad	0x9999999999999999
+phys_base_plus2:
+	.quad	0x8888888888888888
+phys_base_plus3:
+	.quad	0x7777777777777777
 
 #include "../../x86/xen/xen-head.S"
 	


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Olaf Hering <olaf@aepfle.de>
To: kexec@lists.infradead.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: incorrect layout of globals from head_64.S during kexec boot
Date: Thu, 5 Jul 2012 23:06:07 +0200	[thread overview]
Message-ID: <20120705210607.GA26908@aepfle.de> (raw)


During kexec in a Xen PVonHVM guest the new kernel crashes most of the
time in secondary_startup_64 because the content of phys_base is
corrupted. Its not zero as expected but has some random other values.
While debugging that crash I came up with the change below to inspect
the memory around phys_base. 

It turned out that the globales are not in the expected memory location.
An expected value such as phys_base_plus1 is shifted, but by a different
amount during repeated kexec attempts. Up to now I havent figured out
where this happens.

My question is: were to put additional debug to trace the copying of the
data section to its final destination? Is this a task of kexec -l or
does that happen during decompressing? I suspect the latter. This is the
console output before the crash (the crash happens in 'movq %rax, %cr3'):

...
[   44.072548] Starting new kernel
I'm in purgatory
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
...


example xenctx output:
rip: 0000000001000146
flags: 00010086 rf s nz p
rsp: 0000000002119c80
rax: 888888888a495999   rcx: 00000000000003d5   rdx: 0000000001000000
rbx: 0000000001cac000   rsi: 0000000000003000   rdi: 0000000001c13000
rbp: 0000000000000000    r8: 0000000001c13000    r9: 1111111111112222
r10: 0000000000001111   r11: 9999999999990000   r12: 8888888888889999
r13: 7777777777778888   r14: 0000000000007777   r15: 0000000000000000
 cs: 0010        ss: 0000        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ 0000000000000000/0000000000000000

cr0: 80000011
cr2: ffffffffff600400
cr3: 0211a000
cr4: 000000a0

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: ffff0ff0
dr7: 00000400
Code (instr addr 01000146)
a0 00 00 00 0f 22 e0 48 c7 c0 00 c0 c0 01 48 03 05 02 3f c1 00 <0f> 22 d8 48 c7 c0 52 01 00 81 ff



diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 94bf9cc..999807c 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -69,6 +69,22 @@ startup_64:
 	/* Compute the delta between the address I am compiled to run at and the
 	 * address I am actually running at.
 	 */
+#if 1
+	movq	$phys_base - __START_KERNEL_map, %rdx
+	movq	phys_base_minus5(%rip),%rbp
+	movq	phys_base_minus4(%rip),%r8
+	movq	phys_base_minus3(%rip),%r9
+	movq	phys_base_minus2(%rip),%r10
+	movq	phys_base_minus1(%rip),%r11
+	movq	phys_base(%rip),%r12
+	movq	phys_base_plus1(%rip),%r13
+	movq	phys_base_plus2(%rip),%r14
+	movq	phys_base_plus3(%rip),%r15
+#if 0
+	ud2a
+	hlt
+#endif
+#endif
 	leaq	_text(%rip), %rbp
 	subq	$_text - __START_KERNEL_map, %rbp
 
@@ -166,6 +182,10 @@ ENTRY(secondary_startup_64)
 	/* Setup early boot stage 4 level pagetables. */
 	movq	$(init_level4_pgt - __START_KERNEL_map), %rax
 	addq	phys_base(%rip), %rax
+#if 0
+	ud2a
+	hlt
+#endif
 	movq	%rax, %cr3
 
 	/* Ensure I am executing from virtual addresses */
@@ -439,10 +459,28 @@ early_gdt_descr:
 	.word	GDT_ENTRIES*8-1
 early_gdt_descr_base:
 	.quad	INIT_PER_CPU_VAR(gdt_page)
-
-ENTRY(phys_base)
+	.align 32
+phys_base_minus5:
+	.quad	0x5555555555555555
+phys_base_minus4:
+	.quad	0x4444444444444444
+phys_base_minus3:
+	.quad	0x3333333333333333
+phys_base_minus2:
+	.quad	0x2222222222222222
+phys_base_minus1:
+	.quad	0x1111111111111111
+
+	.globl phys_base
+phys_base:
 	/* This must match the first entry in level2_kernel_pgt */
 	.quad   0x0000000000000000
+phys_base_plus1:
+	.quad	0x9999999999999999
+phys_base_plus2:
+	.quad	0x8888888888888888
+phys_base_plus3:
+	.quad	0x7777777777777777
 
 #include "../../x86/xen/xen-head.S"
 	


             reply	other threads:[~2012-07-05 21:06 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-05 21:06 Olaf Hering [this message]
2012-07-05 21:06 ` incorrect layout of globals from head_64.S during kexec boot Olaf Hering
2012-07-06  8:29 ` [Xen-devel] " Jan Beulich
2012-07-06  8:29   ` Jan Beulich
2012-07-06  8:29   ` Jan Beulich
2012-07-06  8:41 ` Daniel Kiper
2012-07-06  8:41   ` Daniel Kiper
2012-07-06  8:41   ` Daniel Kiper
2012-07-06 12:07   ` Olaf Hering
2012-07-06 12:07     ` Olaf Hering
2012-07-06 12:56     ` [Xen-devel] " Jan Beulich
2012-07-06 12:56       ` Jan Beulich
2012-07-06 12:56       ` Jan Beulich
2012-07-06 13:31       ` Olaf Hering
2012-07-06 13:31         ` Olaf Hering
2012-07-06 13:31         ` Olaf Hering
2012-07-06 13:53         ` Jan Beulich
2012-07-06 13:53           ` Jan Beulich
2012-07-06 13:53           ` Jan Beulich
2012-07-06 14:14         ` Olaf Hering
2012-07-06 14:14           ` Olaf Hering
2012-07-06 14:50           ` Jan Beulich
2012-07-06 14:50             ` Jan Beulich
2012-07-06 14:50             ` Jan Beulich
2012-07-06 17:29             ` Olaf Hering
2012-07-06 17:29               ` Olaf Hering
2012-07-10  9:33               ` Olaf Hering
2012-07-10  9:33                 ` Olaf Hering
2012-07-10 14:14                 ` Konrad Rzeszutek Wilk
2012-07-10 14:14                   ` Konrad Rzeszutek Wilk
2012-07-10 14:46                   ` Ian Campbell
2012-07-10 14:46                     ` Ian Campbell
2012-07-10 14:51                     ` Konrad Rzeszutek Wilk
2012-07-10 14:51                       ` Konrad Rzeszutek Wilk
2012-07-10 14:51                       ` Konrad Rzeszutek Wilk
2012-07-10 15:29                       ` Ian Campbell
2012-07-10 15:29                         ` Ian Campbell
2012-07-10 15:29                         ` Ian Campbell
2012-07-10 15:37                         ` Olaf Hering
2012-07-10 15:37                           ` Olaf Hering
2012-07-10 15:23                   ` Olaf Hering
2012-07-10 15:23                     ` Olaf Hering
2012-07-10 17:26                     ` Konrad Rzeszutek Wilk
2012-07-10 17:26                       ` Konrad Rzeszutek Wilk
2012-07-10 17:26                       ` Konrad Rzeszutek Wilk
2012-07-10 18:09                       ` Olaf Hering
2012-07-10 18:09                         ` Olaf Hering
2012-07-10 18:32                         ` Konrad Rzeszutek Wilk
2012-07-10 18:32                           ` Konrad Rzeszutek Wilk
2012-07-10 19:08                         ` Keir Fraser
2012-07-10 19:08                           ` Keir Fraser
2012-07-10 19:08                           ` Keir Fraser
2012-07-13 20:20                           ` Olaf Hering
2012-07-13 20:20                             ` Olaf Hering
2012-07-14  4:54                             ` Keir Fraser
2012-07-14  4:54                               ` Keir Fraser
2012-07-14  4:54                               ` Keir Fraser
2012-07-15 16:06                           ` Olaf Hering
2012-07-15 16:06                             ` Olaf Hering
2012-07-15 17:17                             ` Keir Fraser
2012-07-15 17:17                               ` Keir Fraser
2012-07-15 17:17                               ` Keir Fraser
2012-07-16 15:46                             ` Konrad Rzeszutek Wilk
2012-07-16 15:46                               ` Konrad Rzeszutek Wilk
2012-07-17 10:24                               ` Olaf Hering
2012-07-17 10:24                                 ` Olaf Hering
2012-07-17 12:34                                 ` Olaf Hering
2012-07-17 12:34                                   ` Olaf Hering
2012-07-06 15:54     ` Daniel Kiper
2012-07-06 15:54       ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120705210607.GA26908@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.