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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Is there any chance you could configure your MUA for ">" style quoting?

On Wed, 2013-06-26 at 15:09 +0000, Eric Trudeau wrote:
> (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".

You may want to pull up to 47a1d0b48ce3010c1b119541353cb1a7b5ed5de9 to
get the fix for the XSA-55 regression I mentioned.

> 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
> issues)
> 
> > 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
> at
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling
>  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 would highly (*very* highly) recommend that you integrate a more
recent upstream libaio into your rootfs and cross environment rather
than using the tools/libaio source which comes from Xen.

The homepage on kernel.org seems dead but you could use Debian upstream
tarball:
http://ftp.de.debian.org/debian/pool/main/liba/libaio/libaio_0.3.109.orig.tar.gz

> > 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. :)

This sounds like the XSA-55 regression I referred to. If you pull up to
the commit I mention above (which is currently in staging and will
propagate to master after automated test, hopefully overnight) then this
problem should go away.

Ian.


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