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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Oct 31, 2013 at 06:30:32PM +0000, David Vrabel wrote:
> On 31/10/2013 16:59, Don Slutz wrote:
> > 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
>
> Looks like heap corruption.  I'll look into this.
>
> >>>>> 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.
>
> Thanks for tracking this down. This should be fixed in the tools by
> correctly aligning that segment.

I have rebuild all binaries and results are the same. Configuration
changes does not help too. Don's patches solve some issues but dump
system still does not load (I use Linux Kernel 3.10.17). I can see
only following messages in all cases:

I'm in purgatory
early console in decompress_kernel

I am going to investigate this further at the beginning of next week
(probably on Monday). If you find something new drop me a line.

Daniel

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