Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-12-01 at 08:41 +0100, Juergen Gross wrote:
> >> I'm not quite sure what to make of this, in particular I don't see
> anything
> >> in kexec.c which obviously looks after unmapping the heap or brk
> areas.
> > 
> > Nah, this backtrace shows a normal allocation path while
> > uncompressing the kernel image. I'd expect something like that.
> > Why shouldn't mini-os make use of pfn 4d81 somewhere?

That pfn ends up right in the middle of the next-kernels vaddr mapping,
so at best it indicates some sort of disconnect/overlap between the
mini-os memory allocator and the domain-builder memory allocator.

Since it seems to be in the middle of the padding area (which might
have been new in ea7c8a3d0e82, I'm not sure, it seems to be more
explicit at the least) it occurred to me on the way home last night
that maybe we need to unmap the padding area as well.

I'll try that and your suggested patch below as well once I get to the
office this morning.

> > 
> > I guess there is something wrong either in mini-os's memory
> > allocator (not very likely) or in kexec_allocate(). I'll try to
> > check those.
> 
> Hmm, kexec_allocate() seems to be a little bit fishy.
> 
> I suspect a problem in the loop for the case new_pfn == i. I think
> in this case the p2m list will be written with a wrong entry.
> 
> Ian, could you verify via:
> 
> diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
> index 8fd9ff9..9421023 100644
> --- a/stubdom/grub/kexec.c
> +++ b/stubdom/grub/kexec.c
> @@ -131,6 +131,8 @@ int kexec_allocate(struct xc_dom_image *dom)
>       /* Store destination PFN of currently requested page. */
>       pages_moved2pfns[i] = new_pfn;
> 
> +     BUG_ON(new_pfn == i);
> +
>       /* Put old page at new PFN */
>       dom->p2m_host[new_pfn] = old_mfn;
> 
> 
> Juergen

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