WARNING - OLD ARCHIVES

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

xen-devel

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel