Re: [Xen-devel] Sparc32/64 porting effort, interest?

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

On Aug 9, 2006, at 2:10 AM, Tristan Gingold wrote:

> Le Samedi 05 Août 2006 23:05, Blue Swirl a écrit :
> > Hi,
> >
> > I've developed some bits for Qemu and OpenBIOS Sparc32/64 versions  
> > and I
> > know their internals. Maybe I could use that knowledge to port Xen  
> > to Sparc
> > platforms.
> >
> > Can somone guesstimate what kind of effort would be needed for  
> > Sparc32 port
> > targeted at hardware emulated by Qemu (SS5), for example?
> >
> > Are there other developers interested in Sparc port?
Actually, I'm a big fan of the SPARC architecture, I would happy to  
watch a lob some help here and there but I can;t say I'd contribute  
much.
> Big questions!
>
> Which hardware are you targetting ?  Sparc or SparcV9?
>
> Sparc doesn't have a three level protection mechanism.  So adding a  
> VMM can be
> tricky.
Actually its easier, unlike those "three level" guys SPARC (and PPC)  
has a clean separation for what can and cannot be done in the 2 modes  
supported.  So I'd be pushing the Linux kernel into user space, using  
really simple hvcalls() to virtualize memory then write a nice  
Illeagal/protected instruction recovery mechanism.
After that you can start extending the paravirt ops to take care of  
stuff.
*** NOTE: Some PPC chips do provide a third hypervisor mode, but  
thats simply for some extra performance ***
Linux should not be too hard because the Linux Sparc code has  
excellent abstractions and with the new Niagra stuff, you may find  
the abstractions are "just right".
> PowerPc people may have ideas to handle this case.
We have an experimental mode that pushes the kernel into user mode,  
it requires Xen to craft initial memory spaces like a real-mode  
mapping and kernel-virtual mapping that is usually V-maps-P.
One thing that we have played with is the ability to create "virtual  
supervisor register" space in the last virtual page (0-4k), that has  
increased performance.
You should be able to do the same with SPARC since you can have linux  
"fixup" all 'RD <reg>, Rx' instructions to  'LD r3,-<reg * 8>'.
** and you guys thought the simm13 mode was useless :)

BTW: the above was thought up by <mostrows@xxxxxxxxxxxxxx>


> On the pros side, sparc doesn't have an arch-defined MMU, so you  
> can create
> you own para-virtualized MMU fitting well into Xen.
>
> AFAIK, only Niagara has a three level protection.  Maybe only  
> niagara makes
> sense for Xen.
Biggest draw-back for this is that there is already a hypervisor  
sitting there :) and a smaller number of platforms by which people  
can enjoy the fruits of you labour.
Go for the usermode, at least you'll have a larger number of  
platforms available for users.
> Porting Xen requires a very good knowledge of the CPU (and of Xen  
> internals of
> course).
That is true, if you stick with use mode then everything you need to  
learn has been written a bazillian times and Linux can be your guide.
>   PowerPC people may give you a better time estimation; a rough one
> may be <1 year to run dom0 and <1 year to run domU.
I truly think we could have had a pure user mode a lot quicker, but  
this is a good estimate.
Your first task, is to port the zilog UART :)
I'd love the opportunity to share OF code, and we have a small  
partition firmwaware that give Dom0 the appearance of real OF in a  
domain.
Please reuse.

> At the last XenSummit, there was at least one people from Sun.  I  
> don't know
> wether other developers are interested.
No Sparc people, I was looking. :(

-JX


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel