>-----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
|