The following changeset breaks Xen support for tboot (the version of tboot in SourceForge/bughost as well as with recent patches). I am trying to see what aspect of this is causing the problem, but if perhaps someone could see something obvious and save me some time... The error is: (XEN) Early fatal page fault at e008:ffff828c80117c22 (cr2=0000000001157202, ec0000) (XEN) Stack dump: 0000000000021c20 0000000000000378 ffff828c801ee0c1 ffff828c801 ed6c1 ffff828c801ed4e0 0000000001157000 ffff828c80123680 00000000ffffffff 000000 0000000000 0000000000000000 0000000000f17e00 0000000000000004 0000000000000004 f fff828c801ca6bd 0000000001157202 0000000000000000 ffff828c80117c22 000000000000e 008 0000000000010002 ffff828c80257e40 0000000000000000 ffff828c80200245 00000000 01157000 ffff828c80200289 ffff830000000000 ffff828c801fdbd7 0000000000000000 000 0000000000000 0000000000000000 0000000000000000 0000000000000000 000000000000000 0 0000000000000000 0000000000000000 ffff83000002cea0 ffff830000021c20 0000000000 f17e00 0000000000000000 0000000800000000 000000010000006e 0000000000000003 00000 000000002f8 0000000000000000 0000000000000000 0000000000000001 000000007a01f9f0 000000007a316018 0000000000000000 0000000000000000 ffff828c801000b5 000000000000 0000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000 000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00 00000000000000 0000000000000000 0000000000000000 0000000000000000 00000000000000 00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000 0000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000 000000000000 0000000000000000 00000000fffff000 Joe changeset: 19075:9b0289a165eb user: Keir Fraser <keir.fraser@citrix.com> date: Thu Jan 22 18:00:48 2009 +0000 files: xen/arch/x86/Makefile xen/arch/x86/bzimage.c xen/arch/x86/domain_build.c xen/arch/x86/setup.c xen/common/inflate.c xen/include/xen/sched.h description: x86: Support booting a bzImage format domain 0 kernel. This requires a bzImage v2.08 or later kernel. xen/common/inflate.c is taken unmodified from Linux v2.6.28. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On > Behalf Of Cihula, Joseph > Sent: Wednesday, January 28, 2009 2:19 PM > > The following changeset breaks Xen support for tboot (the version of tboot in > SourceForge/bughost as well as with recent patches). I am trying to see what aspect of this > is causing the problem, but if perhaps someone could see something obvious and save me some > time... > > The error is: > (XEN) Early fatal page fault at e008:ffff828c80117c22 (cr2=0000000001157202, ec> 0000) > (XEN) Stack dump: 0000000000021c20 0000000000000378 ffff828c801ee0c1 ffff828c801 > ed6c1 ffff828c801ed4e0 0000000001157000 ffff828c80123680 00000000ffffffff 000000 > 0000000000 0000000000000000 0000000000f17e00 0000000000000004 0000000000000004 f > fff828c801ca6bd 0000000001157202 0000000000000000 ffff828c80117c22 000000000000e > 008 0000000000010002 ffff828c80257e40 0000000000000000 ffff828c80200245 00000000 > 01157000 ffff828c80200289 ffff830000000000 ffff828c801fdbd7 0000000000000000 000 > 0000000000000 0000000000000000 0000000000000000 0000000000000000 000000000000000 > 0 0000000000000000 0000000000000000 ffff83000002cea0 ffff830000021c20 0000000000 > f17e00 0000000000000000 0000000800000000 000000010000006e 0000000000000003 00000 > 000000002f8 0000000000000000 0000000000000000 0000000000000001 000000007a01f9f0 > 000000007a316018 0000000000000000 0000000000000000 ffff828c801000b5 000000000000 > 0000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000 > 000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00 > 00000000000000 0000000000000000 0000000000000000 0000000000000000 00000000000000 > 00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000 > 0000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000 > 000000000000 0000000000000000 00000000fffff000 > > Joe > > changeset: 19075:9b0289a165eb > user: Keir Fraser <keir.fraser@citrix.com> > date: Thu Jan 22 18:00:48 2009 +0000 > files: xen/arch/x86/Makefile xen/arch/x86/bzimage.c xen/arch/x86/domain_build.c > xen/arch/x86/setup.c xen/common/inflate.c xen/include/xen/sched.h > description: > x86: Support booting a bzImage format domain 0 kernel. > > This requires a bzImage v2.08 or later kernel. > > xen/common/inflate.c is taken unmodified from Linux v2.6.28. > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > >I''ve traced this down to the bzimage_check() fn where it is trying to check if the header string is there--the memcmp() is faulting. But I don''t know why yet (the module start addr is 0x1157000 and the header is at 0x1157202). But I think there is a bug in either bzimage_check() or bzimage_headroom(). bzimage_headroom() calls bzimage_check() as so: err = bzimage_check(hdr, image_length); if (err < 1) return err; where bzimage_headroom() returns the size of headroom to leave to expand the image. However, one of the code paths in bzimage_check() is: if ( hdr->version < VERSION(2,8) ) { printk("Cannot load bzImage v%d.%02d at least v2.08 is required\n", hdr->version >> 8, hdr->version & 0xff); return -EINVAL; } If this path is taken then bzimage_check() will return -22 (EINVAL is 22), which bzimage_headroom() will then return, which gets assigned to modules_headroom in __start_xen() and modules_headroom is an unsigned long--hence it will get a very large value. I think that all failure paths in bzimage_headroom() should return 0? Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> From: Cihula, Joseph > Sent: Wednesday, January 28, 2009 4:32 PM > > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] > On > > Behalf Of Cihula, Joseph > > Sent: Wednesday, January 28, 2009 2:19 PM > > > > The following changeset breaks Xen support for tboot (the version of tboot in > > SourceForge/bughost as well as with recent patches). I am trying to see what aspect of this > > is causing the problem, but if perhaps someone could see something obvious and save me some > > time... > > > > The error is: > > (XEN) Early fatal page fault at e008:ffff828c80117c22 (cr2=0000000001157202, ec> > 0000) > > (XEN) Stack dump: 0000000000021c20 0000000000000378 ffff828c801ee0c1 ffff828c801 > > ed6c1 ffff828c801ed4e0 0000000001157000 ffff828c80123680 00000000ffffffff 000000 > > 0000000000 0000000000000000 0000000000f17e00 0000000000000004 0000000000000004 f > > fff828c801ca6bd 0000000001157202 0000000000000000 ffff828c80117c22 000000000000e > > 008 0000000000010002 ffff828c80257e40 0000000000000000 ffff828c80200245 00000000 > > 01157000 ffff828c80200289 ffff830000000000 ffff828c801fdbd7 0000000000000000 000 > > 0000000000000 0000000000000000 0000000000000000 0000000000000000 000000000000000 > > 0 0000000000000000 0000000000000000 ffff83000002cea0 ffff830000021c20 0000000000 > > f17e00 0000000000000000 0000000800000000 000000010000006e 0000000000000003 00000 > > 000000002f8 0000000000000000 0000000000000000 0000000000000001 000000007a01f9f0 > > 000000007a316018 0000000000000000 0000000000000000 ffff828c801000b5 000000000000 > > 0000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000 > > 000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00 > > 00000000000000 0000000000000000 0000000000000000 0000000000000000 00000000000000 > > 00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000 > > 0000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000 > > 000000000000 0000000000000000 00000000fffff000 > > > > Joe > > > > changeset: 19075:9b0289a165eb > > user: Keir Fraser <keir.fraser@citrix.com> > > date: Thu Jan 22 18:00:48 2009 +0000 > > files: xen/arch/x86/Makefile xen/arch/x86/bzimage.c xen/arch/x86/domain_build.c > > xen/arch/x86/setup.c xen/common/inflate.c xen/include/xen/sched.h > > description: > > x86: Support booting a bzImage format domain 0 kernel. > > > > This requires a bzImage v2.08 or later kernel. > > > > xen/common/inflate.c is taken unmodified from Linux v2.6.28. > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > > > > > > I''ve traced this down to the bzimage_check() fn where it is trying to check if the header > string is there--the memcmp() is faulting. But I don''t know why yet (the module start addr is > 0x1157000 and the header is at 0x1157202).OK, so the problem is that tboot loads at 16MB (0x1000000) and the multiboot modules load after it. tboot relocates Xen to lower memory but not the modules, since Xen needs to move them anyway. But at this point in __start_xen(), that region of memory is not mapped to xen yet and so it faults. But by the time xen is ready to move the modules, they are mapped and hence why there was no problem before. The below patch moves the call to bzimage_headroom() to just before its needed and by this time the modules are mapped. This makes Xen work correctly with tboot. Caveat, I haven''t tested with a bzImage dom0, but the code is the same, just moved. diff -r 31983c30c460 xen/arch/x86/setup.c --- a/xen/arch/x86/setup.c Tue Jan 27 16:41:09 2009 +0000 +++ b/xen/arch/x86/setup.c Wed Jan 28 15:52:46 2009 -0800 @@ -417,7 +417,7 @@ void __init __start_xen(unsigned long mb unsigned int initrdidx = 1; multiboot_info_t *mbi = __va(mbi_p); module_t *mod = (module_t *)__va(mbi->mods_addr); - unsigned long nr_pages, modules_length, modules_headroom; + unsigned long nr_pages, modules_length, modules_headroom = -1; unsigned long allocator_bitmap_end; int i, e820_warn = 0, bytes = 0; struct ns16550_defaults ns16550 = { @@ -617,9 +617,6 @@ void __init __start_xen(unsigned long mb * x86/64, we relocate Xen to higher memory. */ modules_length = mod[mbi->mods_count-1].mod_end - mod[0].mod_start; - modules_headroom = bzimage_headroom( - (char *)(unsigned long)mod[0].mod_start, - (unsigned long)(mod[0].mod_end - mod[0].mod_start)); for ( i = boot_e820.nr_map-1; i >= 0; i-- ) { @@ -723,6 +720,12 @@ void __init __start_xen(unsigned long mb "D" (__va(__pa(cpu0_stack))), "c" (STACK_SIZE) : "memory" ); } #endif + + if ( modules_headroom == -1 ) { + modules_headroom = bzimage_headroom( + (char *)(unsigned long)mod[0].mod_start, + (unsigned long)(mod[0].mod_end - mod[0].mod_start)); + } /* Is the region suitable for relocating the multiboot modules? */ if ( !initial_images_start && (s < e) && Signed-off-by: Joseph Cihula <joseph.cihula@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/01/2009 00:31, "Cihula, Joseph" <joseph.cihula@intel.com> wrote:> If this path is taken then bzimage_check() will return -22 (EINVAL is 22), > which bzimage_headroom() will then return, which gets assigned to > modules_headroom in __start_xen() and modules_headroom is an unsigned > long--hence it will get a very large value. I think that all failure paths in > bzimage_headroom() should return 0?I suspect callers of bzimage_headroom() are supposed to check for negative return values. Seems easier just to return 0 really, as you suggest. Of course, this isn''t your actual bug. :-( -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel