WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-arm

RE: [XenARM] Initial porting on Xscale

To: "George G. Davis" <gdavis@xxxxxxxxxx>
Subject: RE: [XenARM] Initial porting on Xscale
From: "ROSSIER Daniel" <Daniel.Rossier@xxxxxxxxxx>
Date: Wed, 3 Oct 2007 19:03:32 +0200
Cc: xen-arm@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 03 Oct 2007 10:04:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071002150523.GF29648@xxxxxxxxxx>
List-help: <mailto:xen-arm-request@lists.xensource.com?subject=help>
List-id: Xen ARM development <xen-arm.lists.xensource.com>
List-post: <mailto:xen-arm@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm>, <mailto:xen-arm-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm>, <mailto:xen-arm-request@lists.xensource.com?subject=unsubscribe>
References: <FDBBB5CC70676540B3EF7CFE83FD94E0B475FD@xxxxxxxxxxxxxxxxxxxxxxx> <20071002150523.GF29648@xxxxxxxxxx>
Sender: xen-arm-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgFBbEEMUBH4PxaQQqF/ALQKW0TcAA0oO4A
Thread-topic: [XenARM] Initial porting on Xscale
>-----Original Message-----
>From: George G. Davis [mailto:gdavis@xxxxxxxxxx]
>Sent: mardi 2 octobre 2007 17:05
>To: ROSSIER Daniel
>Cc: xen-arm@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [XenARM] Initial porting on Xscale
>
>On Fri, Sep 28, 2007 at 08:55:41PM +0200, ROSSIER Daniel wrote:
>>
>> Hello,
>>
>> 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
>debuggers,
>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
tools.
>Using QEMU for this task is quite convenient since gdbserver support is
>builtin so low-level target debugging can be performed on your
>development
>host with no ARM hardware and/or ARM debugging tools required.  Alas
>QEMU
>may not include support for your specific target.

Yes, it is a good idea to start with QEMU. We actually started with the
board directly
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
domain-0/U version
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
the
>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
>soon.
>
>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
anyway.

>
>
>> Any hints, comments, suggestions, contributions are highly welcome
and
>helpful.
>>
>> Thanks a lot
>>
>> Daniel
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-arm mailing list
>> Xen-arm@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm
>
>--
>Regards,
>George

_______________________________________________
Xen-arm mailing list
Xen-arm@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm

<Prev in Thread] Current Thread [Next in Thread>