[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XenARM] XEN tools for ARM with Virtualization Extensions

  • To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • From: "Eric Trudeau" <etrudeau@xxxxxxxxxxxx>
  • Date: Wed, 26 Jun 2013 15:09:58 +0000
  • Accept-language: en-US
  • Delivery-date: Wed, 26 Jun 2013 15:10:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac5x/hIn6nqf5EjJTZqDwdCaQWsF7gAiYrQAAAJe3uA=
  • Thread-topic: [XenARM] XEN tools for ARM with Virtualization Extensions

(moving to xen-devel, xen-arm is for the older PV ARM port)

On Tue, 2013-06-25 at 23:59 +0000, Eric Trudeau wrote:
> Hi, I am trying to build the XEN tools for our port of XEN to our
> Cortex A15-based platform.
> I am using the repo at git://xenbits.xenproject.org/xen.git to
> cross-compile the tools into our rootfs.

Which branch/changeset are you using?

[EPT] We are currently based on commit, "8ee5e39 QEMU_TAG update".

I've heard that the recent XSA-55 fixes have broken guest loading on
ARM, but your problems do not seem to be related to that (I mention it
because it might be something you hit after we work through your current

> This repo is what we are using for our Hypervisor development also.
> When building the tools, I found that libaio does not build for ARM
> since it was missing tools/libaio/src/syscall-arm.h.
> I found a version on the web so that I could continue.

Are you picking up the libaio in tools/libaio? That is an ancient
snapshot used to support older distros which don't ship libaio
themselves. It really shouldn't even be considered for ARM (this is a
bug in our build system IMHO). If you install the libaio (and headers
etc) from your distro then configure will detect this and not use the
embedded copy. (The embedded copy is on my hitlist for cruft removal for
4.4, but we are frozen for 4.3 right now so I can't touch it)

FWIW I wrote up some details of how I cross compile with Debian/Ubuntu
which includes lists of packages to install etc.

[EPT] We have our own rootfs since this is an embedded platform with many 
custom devices.  I will try to debug the issues with
the tools/libaio unless I find that the issue seems to be with that module.

> I also found that xc_dom_elfloader.câs function, xc_dom_guest_type(),
> did not know about the EM_ARM machine type.

You shouldn't be hitting the elf loader paths, you should instead use
the zImage version of the kernel which will hit the
xc_dom_armzimageloader.c code paths.

We did at one point in the very early days of the port support loading
ELF files via a quick hack of a tool ("xcbuild") but that has been
superceded by the proper toolstack support and the use of zImage.

[EPT] I noticed when I used my zImage that it seemed to check for a gzip magic 
number so I thought maybe I should not use it.
I will go back to using the zImage since I believe the issue is the same.  It 
appears that virt_base and virt_alloc_end are invalid.
I will try to find out how these are supposed to be determined.  Any tips would 
be welcome. :)

> Am I using the wrong repo for development of the tools for ARM?

> If not, the twiki seems to indicate that xl is working on ARM to
> create guest machines.

Modulo any bugs introduced by XSA-55 we believe it is.


Xen-devel mailing list



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