[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Bare-metal Xen on ARM boot
On 1 May 2013 11:27, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Wed, 2013-05-01 at 09:55 +0100, Sander Bogaert wrote: >> > This patch got me further in booting the domain but still got stuck. I >> > was adding extra print's to find out where exactly. Here is the >> > stacktrace ( attached the whole output too) : >> > >> > domainbuilder: detail: xc_dom_build_image: called >> > domainbuilder: detail: xc_dom_alloc_segment: kernel : >> > 0x80000000 -> 0x80011000 (pfn 0x80000 + 0x11 pages) >> > domainbuilder: detail: xc_dom_pfn_to_ptr: pfn 80000 out of range >> > (0x80000 > 0x2000) > > This could be due to confusion about where the RAM base starts. > > On x86 RAM starts at zero and so the domain builder had/has some > assumptions about that in it. So your image appears to be linked at > 0x8000000 (a common RAM base on ARM, and the one we currently expose to > guest virtual machines, good) but the domain builder thinks memory is > 0x0...0x2000000, bad. > > I added rambase_pfn to xc_dom_image to address this. > tools/libxc/xc_dom_armzimageloader.c deals with it but I suspect the ELF > loader doesn't. You could probably hack an assignment in somewhere. > > I wonder if RAM base ought to be part of xc_dom_arch and set the default > in xc_dom_image from that? > > We should also perhaps consider whether 0x80000000 is the right base to > expose to guests. > >> > libxl: error: libxl_dom.c:392:libxl__build_pv: xc_dom_build_image >> > failed: No such file or directory >> > domainbuilder: detail: xc_dom_release: called >> > libxl: error: libxl_create.c:908:domcreate_rebuild_done: cannot >> > (re-)build domain: -3 >> > libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x3aa28: complete, >> > rc=-3 >> > libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x3aa28: >> > inprogress: poller=0x34880, flags=ic >> > libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x3aa28: destroy >> > >> > It ends up in libxl_dom.c:392:libxl__build_pv: xc_dom_build_image >> > failed where there is some x86 specific stuff I think. >> > >> > Thx >> >> Hi, >> >> I was wondering if you had any chance to have a look at this? Would it >> be a big patch to make ELF work? I'm trying to figure it out myself >> but it's not that easy, I'm new to this :-) ( and I had some problems >> compiling the tools again ). Maybe some pointers could help me create >> this patch myself? > > I'm afraid this probably isn't going to float to the top of my TODO list > any time soon, sorry. > > If it doesn't turn out to be the rambase thing I mention above then it's > worth noting that before we had libxl integration we had a hacky > "xcbuild" binary[0] which at least at one point supported booting from > ELF files. I wouldn't recommend using xcbuild now but it might be useful > to compare the libxc calls it makes with those made by libxl. (Fair > warning: this might be bad advice and lead you down the wrong path, > there are a couple of different ways you can use the libxc domain > builder IIRC). > > > [0] > http://xenbits.xen.org/gitweb/?p=people/ianc/xen.git;a=shortlog;h=refs/heads/arm-xcbuild >> >> Sander > > I thought I send a small update: After finally understanding what needed to be done ( and some compilation struggles ) I made the suggested change. Basically I just added one line to set the rambase when loading an ELF ( see below ). This seems to work for my custom binary, as far as I can tell from the logs it boots but immediatly crashes ( see attached log ). For the Linux ELF binary, linuxvm this doesnt work ( see log ). I think it's because it has some address hardcoded in it? So my questions: Can I get a small confirmation my custom binary boots and crashes after a succesful boot? :-) Any tips on the linux kernel case? I don't really need this but maybe I can whip up a real patch and submit it ( it would be a very small one but it's a start )? My changes: diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c index 911f316..9b6a847 100644 --- a/tools/libxc/xc_dom_elfloader.c +++ b/tools/libxc/xc_dom_elfloader.c @@ -31,6 +31,8 @@ #define XEN_VER "xen-3.0" +#define ARM_GUEST_RAM_BASE 0x80000000 + /* ------------------------------------------------------------------------ */ static void log_callback(struct elf_binary *elf, void *caller_data, @@ -297,6 +299,9 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom) dom->kernel_seg.vstart = dom->parms.virt_kstart; dom->kernel_seg.vend = dom->parms.virt_kend; + /* this should only be done for arm */ + dom->rambase_pfn = ARM_GUEST_RAM_BASE >> XC_PAGE_SHIFT; + if ( dom->parms.bsd_symtab ) xc_dom_load_elf_symtab(dom, elf, 0); Attachment:
custom_elf.log Attachment:
linux_elf.log _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |