Xen devel - Dec 2004 - Xen/ia64 status (and solicitation for alpha testers and developers)

As some of you have noticed, there is a new architecture (ia64)
in the Xen 2.0 testing and unstable trees.  Though the files
checked into that branch comprise the core hypervisor functionality
for Xen/ia64, there are many additional files required to be
checked in and merged before Xen/ia64 will be buildable and runnable.

Xen/ia64 is increasingly solid but is not yet as capable or
widely-supportable as Xen/x86.  In particular, it currently
only boots one domain -- domain0.  Much of the core infrastructure
is present to support multiple domains and, indeed, I suspect
minimal multi-domain support could be quickly hacked in, but I am
instead trying to ensure that as many of the higher-level APIs
as possible are supported so that the infrastructure (e.g.
xend and all the python stuff) is portable.  I am also working
with the core Xen team to merge changes into common directories
so that Xen/ia64 can more easily track changes to the Xen core
without a bunch of ugly ifdef patches.  These things take time
and so far I have been working solo and part-time on Xen/ia64.

My development/test environment has been limited to an HP rx2600
running Red Hat AS3.2.  Xenlinux/ia64 is currently built from
linux-2.6.9 with only a few minor config tweaks.  Xenlinux must go
through a binary-translation pass after which it is essentially fully
virtualized but as a result is quite slow (4x).  Paravirtualization
is high on my list and will bring performance to near native,
just like Xen/x86.  Ignoring the slowdown, xenlinux (domain0) is
quite robust and -- at least in my tested environment -- runs
all* drivers and user code, even full agpgart graphics.

Early in 2005, Xen/ia64 should be ready for a broader audience.
For now, I am soliciting a small number of alpha testers.  If
you are interested in Xen on ia64, have access to Itanium hardware,
would like to help out with build or development tasks, and have
some skills working with low-level kernel debugging, I''m eager
for your help.  Potential end users should wait for a later release,
however I am still interested in hearing from you.  Note that
like Xen/x86, Xen/ia64 is fully GPL and any help or contribution
will be open source and properly credited.

Happy holidays,
Dan Magenheimer
HP Labs (but based in Fort Collins Colorado USA)
dan.magenheimer <at> hp.com

P.S. I won''t have access to email for the next few days and I am
already a bit behind in keeping up with xen-devel mail so I would
appreciate it if you would cc me directly.  Apologies in advance
that after today I won''t be able to respond until about Dec 16.

* well... nearly all.  There''s a bug somewhere in IDE that I
haven''t
tracked down yet so I can''t use my DVD-ROM :-)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Xenlinux must go 
> through a binary-translation pass after which it is essentially fully
> virtualized but as a result is quite slow (4x).
That sounds interesting - what exactly does the binary translation pass do?

Just curious...

Cheers,
Mark
> Early in 2005, Xen/ia64 should be ready for a broader audience.
> For now, I am soliciting a small number of alpha testers.  If
> you are interested in Xen on ia64, have access to Itanium hardware,
> would like to help out with build or development tasks, and have
> some skills working with low-level kernel debugging, I''m eager
> for your help.  Potential end users should wait for a later release,
> however I am still interested in hearing from you.  Note that
> like Xen/x86, Xen/ia64 is fully GPL and any help or contribution
> will be open source and properly credited.
>
> Happy holidays,
> Dan Magenheimer
> HP Labs (but based in Fort Collins Colorado USA)
> dan.magenheimer <at> hp.com
>
> P.S. I won''t have access to email for the next few days and I am
> already a bit behind in keeping up with xen-devel mail so I would
> appreciate it if you would cc me directly.  Apologies in advance
> that after today I won''t be able to respond until about Dec 16.
>
> * well... nearly all.  There''s a bug somewhere in IDE that I
haven''t
> tracked down yet so I can''t use my DVD-ROM :-)
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Mark Williamson <maw48 <at> cantab.net> writes:
> > Xenlinux must go 
> > through a binary-translation pass after which it is essentially fully
> > virtualized but as a result is quite slow (4x).
> 
> That sounds interesting - what exactly does the binary translation pass do?
> 
> Just curious...
Sorry about the delayed response...

Since Xenlinux/ia64 is demoted, all privileged instructions trap
and are emulated.  The real problem is with "privilege sensitive"
instructions -- those instructions that don''t trap but behave
differently depending on whether they execute privileged or not.
There are three of these on ia64.  Also, there are certain registers
that can be read at any privilege level but can only be written
when privileged.  Examples include the eight "kernel registers"
and the cpuid registers.

All the privilege-sensitive (and reads of write-privilege-sensitive
registers) also need to trap and be emulated.  I force this to
happen by finding and translating all such instructions to other
unique illegal/privilged bit patterns that trap.

This is all slow but, as with x86, paravirtualization will greatly
reduce the number of privops emulated and bring performance to
within a couple percent of native (as demonstrated in our VM''04
paper on vBlades).

Hope that helps!
Dan







-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> All the privilege-sensitive (and reads of write-privilege-sensitive
> registers) also need to trap and be emulated.  I force this to
> happen by finding and translating all such instructions to other
> unique illegal/privilged bit patterns that trap.
OK that''s what was guessing from code in Xen.  It''s quite nice
that this is
workable, in fact!
> This is all slow but, as with x86, paravirtualization will greatly
> reduce the number of privops emulated and bring performance to
> within a couple percent of native (as demonstrated in our VM''04
> paper on vBlades).
Out of interest, what are the modifications likely to look like in terms of 
the source tree?  Will it be necessary to introduce a new (sub?) architecture 
to Linux in order to incorporate them?

Also, do you / will you support legacy IA-32 code?

Sorry for all the questions.  Xen on IA-64 looks very cool stuff!

Cheers,
Mark
>
> Hope that helps!
> Dan
>
>
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Out of interest, what are the modifications likely to look 
> like in terms of 
> the source tree?  Will it be necessary to introduce a new 
> (sub?) architecture 
> to Linux in order to incorporate them?
On vBlades, no changes were required to common linux files
and there were two kinds of changes to ia64 archdep, intrusive
and new files.  The intrusive changes required a patch of about
80 lines IIRC and all the changes were "transparent" (e.g.
the linux kernel worked both natively on bare metal and on top
of the VMM), which is my intent for Xen/ia64 as well.
In addition there were several new files that needed to be linked
in (including a paravirtualized version of ivt.S which is a very
complicated assembly file).

This was all on linux-2.4.xx.  We''ll see about linux-2.6 soon.

For this low magnitude of change, a new subarch seems unnecessary,
but it could go either way, depending on Linux community
feedback.
 
> Also, do you / will you support legacy IA-32 code?
To the extent that Linux/ia64 does, yes.  There is currently one
privilege-sensitive register that is required that I did not
implement yet (and is used at startup if CONFIG_IA32_SUPPORT
is enabled) and it is all totally untested so it is currently
turned off, but I don''t foresee any major problems.
> Sorry for all the questions.  Xen on IA-64 looks very cool stuff!
Thanks!  We''re working on getting some equipment to Cambridge
so Xen/ia64 can be included in the regular Xen build/test process
early next year.

Dan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel