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? _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tristan Gingold
2006-Aug-09 06:10 UTC
Re: [Xen-devel] Sparc32/64 porting effort, interest?
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?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. PowerPc people may have ideas to handle this case. 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. Porting Xen requires a very good knowledge of the CPU (and of Xen internals of course). 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. At the last XenSummit, there was at least one people from Sun. I don''t know wether other developers are interested. Tristan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@watson.ibm.com>> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Tristan Gingold
2006-Aug-09 13:31 UTC
Re: [Xen-devel] Sparc32/64 porting effort, interest?
Le Mercredi 09 Août 2006 14:31, Jimi Xenidis a écrit :> On Aug 9, 2006, at 2:10 AM, Tristan Gingold wrote: > > Le Samedi 05 Août 2006 23:05, Blue Swirl a écrit :[...]> > 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.Just a note from xen/ia64 history: ia64 has 4 levels (almost like x86). The first implementation of Xen was done without recompiling the Linux kernel: it was simply patched (some level-sensitive instruction were replaced by traps). This allows to focus on Xen only. This maybe simpler.> *** 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 :)On xen/ia64 we also use memory-mapped registers. They are often faster than genuine registers! [...]> > 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. :(You didn''t look hard enough ;-) He was interesting in Xen for Niagara. Tristan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Which hardware are you targetting ? Sparc or SparcV9?My simplistic plan is as follows: - Sparc32 for Qemu - Sparc32 for some real HW - Sparc64 for Qemu - Sparc64 for some real HW I don''t know about guest OSes, Mini-OS could be a start.>Porting Xen requires a very good knowledge of the CPU (and of Xen internals >of >course). 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''m only beginning to grasp Xen internals, but I think I know the CPUs well. Not the real world erratas and their workarounds, performance etc. though. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Your first task, is to port the zilog UART :)I''m trying to get whole thing compile first. Tools and docs were easy, but xen/arch/sparc/asm-offsets.c gives problems. I''ll send a patch when it''s less dirty. Zilog is trivial, I can reuse OpenBIOS or Proll code for example. No sweat.>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.I''d like to reuse some OpenBIOS code for that too. _________________________________________________________________ Don''t just search. Find. Check out the new MSN Search! http://search.msn.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tristan Gingold
2006-Aug-10 07:57 UTC
Re: [Xen-devel] Sparc32/64 porting effort, interest?
Le Mercredi 09 Août 2006 18:09, Blue Swirl a écrit :> >Which hardware are you targetting ? Sparc or SparcV9? > > My simplistic plan is as follows: > - Sparc32 for Qemu > - Sparc32 for some real HW > - Sparc64 for Qemu > - Sparc64 for some real HW > > I don''t know about guest OSes, Mini-OS could be a start.No, you can''t start with mini-os. Dom0 (the first domain) has extended rights: it does the IOs. Mini-OS can only be started as domU. You could of course heavily modify mini-os so that it runs as dom0. But this will be extra work. Tristan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 09 Aug 2006 18:27:49 +0200, "Blue Swirl" <blueswir1@hotmail.com> wrote:> >Your first task, is to port the zilog UART :)> Zilog is trivial, I can reuse OpenBIOS or Proll code for example. No sweat.PROLL does not emulate Zilog. It only sets up the OF tree and leaves the OS free to use it. So, PROLL''s code is fairly useless for your purpose. OpenBIOS, I do not know. But I do not see any need to emulate zs at all, if you plan for paravirtualization. Just add a driver to Linux for some kind of /dev/hvc (bonus points for making it compatible with PPC64). If you want to run binary Solaris in a full virtual setting, then it''s different. Otherwise, use OpenSolaris and add the same hvc there. -- Pete _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jimi Xenidis
2006-Aug-12 14:10 UTC
Re: [Xen-devel] Re: Sparc32/64 porting effort, interest?
On Aug 12, 2006, at 12:33 AM, Pete Zaitcev wrote:> On Wed, 09 Aug 2006 18:27:49 +0200, "Blue Swirl" > <blueswir1@hotmail.com> wrote: > >>> Your first task, is to port the zilog UART :) > >> Zilog is trivial, I can reuse OpenBIOS or Proll code for example. >> No sweat.No, I mean a Zilog driver "in the Hypervisor" so you can get console :) I''d borrow the linux code. Since we are interested in zilog for PPC (use a lot by apple) we have had some luck with a driver that came with maria''s patch: http://lists.xensource.com/archives/html/xen-ppc-devel/2006-05/ msg00028.html I only ask that we work together and not have 3 99% identical zilog driver like linux currently has.> > PROLL does not emulate Zilog. It only sets up the OF tree > and leaves the OS free to use it. So, PROLL''s code is fairly > useless for your purpose. OpenBIOS, I do not know. > > But I do not see any need to emulate zs at all, if you plan > for paravirtualization. Just add a driver to Linux for some > kind of /dev/hvc (bonus points for making it compatible with > PPC64). >the Doms will just use hcalls. -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Since we are interested in zilog for PPC (use a lot by apple) we have had >some luck with a driver that came with maria''s patch: > http://lists.xensource.com/archives/html/xen-ppc-devel/2006-05/ >msg00028.html > >I only ask that we work together and not have 3 99% identical zilog driver >like linux currently has.Looks good to me. Register layout is a bit different in Sparc, 2 byte instead of 16 byte spacing is used. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it''s FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel