[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
Description: Binary data

Attachment: linux_elf.log
Description: Binary data

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.