[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Sparc32/64 porting effort, interest?
On Aug 9, 2006, at 2:10 AM, Tristan Gingold wrote: 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.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 Sparcplatforms.Can somone guesstimate what kind of effort would be needed for Sparc32 porttargeted at hardware emulated by Qemu (SS5), for example? Are there other developers interested in Sparc port? Big questions! Which hardware are you targetting ? Sparc or SparcV9?Sparc doesn't have a three level protection mechanism. So adding a VMM can betricky. 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 createyou own para-virtualized MMU fitting well into Xen.AFAIK, only Niagara has a three level protection. Maybe only niagara makessense 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 ofcourse). 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 knowwether other developers are interested. No Sparc people, I was looking. :( -JX _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |