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/
Home Products Support Community News


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

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

Le Samedi 05 Août 2006 23:05, Blue Swirl a écrit :

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

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

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

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


Xen-devel mailing list