From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: 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) Date: Tue, 1 Dec 2015 08:41:10 +0100 Message-ID: <565D4F16.90800@suse.com> References: <1447335816-31772-1-git-send-email-jgross@suse.com> <1447335816-31772-7-git-send-email-jgross@suse.com> <5655DDDC.5000005@oracle.com> <5656B626.6080305@suse.com> <20151130102002.GF21588@citrix.com> <565C23A6.4080707@suse.com> <1448879699.15768.14.camel@citrix.com> <565C2946.60109@suse.com> <1448880697.15768.17.camel@citrix.com> <1448880756.15768.18.camel@citrix.com> <565C2D10.9060203@suse.com> <1448882606.15768.21.camel@citrix.com> <565C3EFD.40208@suse.com> <1448886931.15768.31.camel@citrix.com> <565C483B.1080908@suse.com> <1448889417.15768.36.camel@citrix.com> <1448890911.15768.39.camel@citrix.com> <565C7631.4000505@suse.com> <1448900736.15768.50.camel@citrix.com> <1448902580.15768.54.camel@citrix.com> <565D4929.1090008@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <565D4929.1090008@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Wei Liu Cc: Boris Ostrovsky , roger.pau@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 01/12/15 08:15, Juergen Gross wrote: > On 30/11/15 17:56, Ian Campbell wrote: >> On Mon, 2015-11-30 at 16:25 +0000, Ian Campbell wrote: >>> (d54) Pinning the boot page table pfn 4be3 / mfn 1bfd71/1bfd71 >>> (d54) pin_table: MFN 1bfd71 >>> (XEN) mm.c:2417:d54v0 Bad type (saw 1400000000000001 != exp 7000000000000000) for mfn 165b81 (pfn 4d81) >> >> I added a "BUG_ON(*pt_pfn == 0x4d81);" to mini-os's new_pt_frame, which >> after some messing with gdb to decode produced this stack trace: >> >> 716e7: arch_do_exit + 9 in section .text >> 66176: do_exit + 28 in section .text >> 6ff68: new_pt_frame + 134 in section .text >> 70401: need_pgt + 410 in section .text >> 706ec: do_map_frames + 284 in section .text >> 66e72: sbrk + 130 in section .text >> 7768e: _sbrk_r + 30 in section .text >> 74fa3: _malloc_r + 1219 in section .text >> 76f3f: _realloc_r + 511 in section .text >> 31035: unsafe_flush + 46 in section .text >> 38bc7: unxz + 480 in section .text >> 310fa: xc_dom_decompress_unsafe + 110 in section .text >> 38cec: xc_try_xz_decode + 45 in section .text >> 286ff: xc_dom_probe_bzimage_kernel + 891 in section .text >> 24613: xc_dom_find_loader + 89 in section .text >> 24d83: xc_dom_parse_image + 58 in section .text >> 19d06: kexec + 1012 in section .text >> 03c27: pv_boot + 97 in section .text >> 08e4b: boot_func + 52 in section .text >> 0ab16: run_script + 294 in section .text >> 10848: run_menu + 3133 in section .text >> 10fb2: cmain + 1444 in section .text >> 04447: main + 303 in section .text >> 66991: call_main + 581 in section .text >> 03423: thread_starter + 9 in section .text >> >> 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? > > 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