Daniel.Rossier at heig-vd
Oct 3, 2007, 10:03 AM
Post #3 of 3
>From: George G. Davis [mailto:gdavis [at] mvista]
>Sent: mardi 2 octobre 2007 17:05
>To: ROSSIER Daniel
>Cc: xen-arm [at] lists
>Subject: Re: [XenARM] Initial porting on Xscale
>On Fri, Sep 28, 2007 at 08:55:41PM +0200, ROSSIER Daniel wrote:
>> We have now started the port of XEN on a Xscale/PXA270 processor
>(actually using a Colibri board from Toradex).
>For those w/o ARM target hardware and/or lacking hardware based
>I'ld recommend using QEMU for bringup and debugging of Xen on ARM. In
>fact, I'ld recommend using QEMU even if you have the hardware and
>Using QEMU for this task is quite convenient since gdbserver support is
>builtin so low-level target debugging can be performed on your
>host with no ARM hardware and/or ARM debugging tools required. Alas
>may not include support for your specific target.
Yes, it is a good idea to start with QEMU. We actually started with the
because we have quite a good knowledge about it and we can deploy and
boot quickly to perform tests.
The initial idea was also to start with a base code and not totally from
scratch, i.e. debugging support
may be sufficient in our case if we work directly with the board.
Nevertheless, it will definitively be
a good thing if somebody could work on a QEMU version of the port. In
order to spare time, we will
send out the code for our board first, code that can be reworked in
order to have a QEMU-supported code.
>> Ongoing work consists at porting the bootstrap code from XEN on the
>ARM without enabling the virtualization
>> mechanisms. The goal is to have a software infrastructure which is
>compliant with the XEN tree organization
>> and to have the right init code which works on the target machine.
>> In summary, what we are doing is to have the bootstrap code which
>gives the hand to the XEN initialization code, which in turns
>> starts the primary domain-0 Linux.
>> The init code will be strongly inspired from Daniel Ferstay's work as
>well as the standard ARM arch-dependent code from the
>> vanilla kernel (we're considering the 2.6.18 version).
>Have you considered using linux-2.6.23-rc as a starting baseline? It
>already includes DomU paravirt support for x86. So perhaps this would
>be a good base line to start adding ARM paravirt support?
Yeap, actually I prefer to use existing code as Daniel Ferstay's one in
a first step.
For this reason, we prepare a Linux-2.6.18-xen-colibri version which is
bootable on our board,
and integrating the hypervisor, domain-0 and domain-U altogether in
order to simplify the port.
We will then separate the tree when we have a working version of the
hypervisor and primary domain.
(at the beginning, we will probably have nothing more than a miniOS-like
considering the available code ;-)).
>> Then, we will gradually enable the virtualization part of the code
>(scheduler, memory manager, etc.) in the hypervisor and adapt the
>> bootstrap code accordingly. How will the XEN concepts be mapped on
>ARM remain an open issue, but for sure the work from Daniel Ferstay
>> and your feedback and contribution will definitively help. I think we
>may also consider the approaches presented by other ARM-target
>hypervisors such as Iguana/L4, Jaluna, etc.
>> I hope to be able to post a first patch for the 2.6.18 kernel pretty
>I hope we're able to collaborate on this but I'm unable to make any
>commitments at this time. : (
Sure we can collaborate; you will be kept informed about our progress
>> Any hints, comments, suggestions, contributions are highly welcome
>> Thanks a lot
>> Xen-arm mailing list
>> Xen-arm [at] lists
Xen-arm mailing list
Xen-arm [at] lists