Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 10/30/13 12:57, David Vrabel wrote:

On 21/10/13 21:20, Daniel Kiper wrote:

On Mon, Oct 21, 2013 at 01:56:09PM +0100, David Vrabel wrote:

On 21/10/13 13:19, Daniel Kiper wrote:

On Sat, Oct 19, 2013 at 12:14:24AM +0100, David Vrabel wrote:

On 18/10/2013 19:40, Daniel Kiper wrote:

On Tue, Oct 08, 2013 at 05:55:01PM +0100, David Vrabel wrote:

The series (for Xen 4.4) improves the kexec hypercall by making Xen
responsible for loading and relocating the image.  This allows kexec
to be usable by pv-ops kernels and should allow kexec to be usable
from a HVM or PVH privileged domain.

I could not load panic image because Xen crashes in following way:

(XEN) ----[ Xen-4.4-unstable  x86_64  debug=y  Tainted:    C ]----

[...]

(XEN) Xen call trace:
(XEN)    [<ffff82d080114ef2>] kimage_free+0x67/0xd2
(XEN)    [<ffff82d0801151f9>] do_kimage_alloc+0x29c/0x2f0
(XEN)    [<ffff82d0801152fe>] kimage_alloc+0xb1/0xe6
(XEN)    [<ffff82d0801144c0>] do_kexec_op_internal+0x68e/0x789
(XEN)    [<ffff82d0801145c9>] do_kexec_op+0xe/0x12
(XEN)    [<ffff82d0802268cb>] syscall_enter+0xeb/0x145

I get the same thing.

The appended patch should fix this crash which only occurs if there's an
error in do_kimage_alloc().

Patch had wrapped lines. I hope that I fixed it properly.
I cannot load panic kernel. kexec fails with following message:

My version of this patch is attached (0001...). It has both crashed right away and not:

(XEN) [2013-10-30 21:26:39] ----[ Xen-4.4-unstable  x86_64  debug=y  Not tainted ]----
(XEN) [2013-10-30 21:26:39] CPU:    7
(XEN) [2013-10-30 21:26:39] RIP:    e008:[<ffff82d08012fd72>] xmem_pool_free+0x6f/0x2e9
(XEN) [2013-10-30 21:26:39] RFLAGS: 0000000000010286   CONTEXT: hypervisor
(XEN) [2013-10-30 21:26:39] rax: ffff8308df5a5e90   rbx: ffff83083f48f9f0   rcx: 000000000001b410
(XEN) [2013-10-30 21:26:39] rdx: 00000000a01164a0   rsi: ffff83083a1ae000   rdi: ffff83083a1af86c
(XEN) [2013-10-30 21:26:39] rbp: ffff830823fbfd88   rsp: ffff830823fbfd68   r8:  000000000000000c
(XEN) [2013-10-30 21:26:39] r9:  0000000010000000   r10: ffff83083f4904f0   r11: 00000000004c6000
(XEN) [2013-10-30 21:26:39] r12: ffff83083a1ae000   r13: ffff83083a1af868   r14: 00007fff5a9b7fc0
(XEN) [2013-10-30 21:26:39] r15: 0000000000000003   cr0: 0000000080050033   cr4: 00000000000426f0
(XEN) [2013-10-30 21:26:39] cr3: 000000066b482000   cr2: ffff8308df5a5e98
(XEN) [2013-10-30 21:26:39] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2013-10-30 21:26:39] Xen stack trace from rsp=ffff830823fbfd68:
(XEN) [2013-10-30 21:26:39]    00000000000000e0 00000000ffffff9d ffff83083f4904f0 ffff83083f48f9f0
(XEN) [2013-10-30 21:26:39]    ffff830823fbfdc8 ffff82d0801304fe ffff830823fbfdc8 00000000ffffff9d
(XEN) [2013-10-30 21:26:39]    ffff83083f4904f0 ffff8800870bb5e8 00007fff5a9b7fc0 0000000000000003
(XEN) [2013-10-30 21:26:39]    ffff830823fbfee8 ffff82d08011450c ffff830823fbfef8 0000000000000000
(XEN) [2013-10-30 21:26:39]    0000000000000002 ffff830823fb10b8 ffff830823fbfe18 ffff82d08012b104
(XEN) [2013-10-30 21:26:39]    ffff8300bf2f4060 000000000066a0cb 0000000000000000 ffff8300bf2f4000
(XEN) [2013-10-30 21:26:39]    ffff82004001f000 00007ff000000003 00000007003e0001 00007f84d993b004
(XEN) [2013-10-30 21:26:39]    000000001ff53720 ffff830823fb1000 ffff830823fbfe68 ffff82d08016fb23
(XEN) [2013-10-30 21:26:39]    ffff830823fbfe88 ffff82d080221348 ffff830823fb1000 ffff830823fbff18
(XEN) [2013-10-30 21:26:39]    ffff830823fbfef8 ffff82d0802214a8 00000000d69204a7 0000000000000000
(XEN) [2013-10-30 21:26:39]    0000000000000217 0000003564eee0a7 0000000000000100 0000003564eee0a7
(XEN) [2013-10-30 21:26:39]    ffff830823fbfed8 ffff82d08016fb23 ffff8300bf2f4000 00007fff5a9b7fc0
(XEN) [2013-10-30 21:26:39]    ffff830823fbfef8 ffff82d0801145d9 00007cf7dc0400c7 ffff82d0802268cb
(XEN) [2013-10-30 21:26:39]    ffffffff810014aa 0000000000000025 0000001efd525f9a 0000001efd60d300
(XEN) [2013-10-30 21:26:39]    0000000000000000 00000021d69204a7 ffff880087debe88 ffff880005d9a500
(XEN) [2013-10-30 21:26:39]    0000000000000286 00007fff5a9b8180 ffff880087191480 000000001ff53720
(XEN) [2013-10-30 21:26:39]    0000000000000025 ffffffff810014aa 0000003564a148e5 00007f84d8f3f004
(XEN) [2013-10-30 21:26:39]    0000000000000004 0001010000000000 ffffffff810014aa 000000000000e033
(XEN) [2013-10-30 21:26:39]    0000000000000286 ffff880087debde0 000000000000e02b d53835942492fce9
...

The auto reboot overwrote the rest.  When it did not crash right away, the next day I got error messages about page table issues.  (I forgot that the request to write hypervisor console data to a file is not the default.)  I hope to still have the data at home.

Best guess at this point is that the error handling still has issues.

kexec_load failed: Cannot assign requested address

This is -EADDRINVALID which means one of

a) the entry point isn't within a segment.
b) one of the segments is not page aligned.
c) one of the segments is not within the crash region.

But the segments kexec has constructed all looked fine to me (and
similar to the segments I see).

I have tracked this down to in kexec-tools:

+    if (info->kexec_flags & KEXEC_ON_CRASH) {
+        set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);
+        xen_segs[s].buf_size = 0;
+        xen_segs[s].dest_maddr = info->backup_src_start;
+        xen_segs[s].dest_size = info->backup_src_size;
+        nr_segments++;
+    }

Which in some cases passes the 1st e820 line which for me is:

(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf63f000 (usable)
...

000000000009b800 is not page aligned and so the test:

         if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) )
            goto out;

Fails.

A possible fix is attached as (0002...) this does allow me to get into the crash kernel.

   -Don Slutz

I'm afraid I cannot reproduce either of your failures.  Are you sure
you've built everything correctly?  In particular has kexec-tools been
built against the correct version of Xen headers?

It looks that I build it correctly but I will double check it.
Could you send me your Xen/Linux boot command lines and kexec
command lines for normal and panic kernel? Could you tell me
what is your RAM size?

AMD Opteron 4264 with 8 GiB RAM.

Xen 4.4-unstable debug=y:

com1=115200,8n1 console=com1 crashkernel=256M@64M

Linux 3.12-rc4

root=/dev/mapper/cam--st09-root ro console=hvc0

Normal image:

build/sbin/kexec --debug --console-serial --serial-baud=115200
--command-line="console=ttyS0,115200n8 maxcpus=1" -l
/boot/vmlinuz-3.11.0.davidvr

Panic image:

build/sbin/kexec --debug --console-serial --serial-baud=115200
--command-line="console=ttyS0,115200n8 maxcpus=1" -p
/boot/vmlinuz-3.11.0.davidvr

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

Attachment: 0001-kexec-v9a-Fix-error-handling-if-do_kimage_alloc-repo.patch
Description: Text Data

Attachment: 0002-kexec-Skip-checking-of-info-backup_src_start-info-ba.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel