[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Pre-virtualization, was Re: linux/arch/xen/i386 or linux/arch/i386/xen




So far, performance seems comparable.

-Josh


On May 20, 2005, at 18:47, Magenheimer, Dan (HP Labs Fort Collins) wrote:

Excellent!  How is performance relative to the manually
paravirtualized xenlinux?


-----Original Message-----
From: Joshua LeVasseur [mailto:jtl@xxxxxxxxxx]
Sent: Friday, May 20, 2005 10:38 AM
To: Magenheimer, Dan (HP Labs Fort Collins)
Cc: Vincent Hanquez; Chris Wright;
xen-devel@xxxxxxxxxxxxxxxxxxx; Mark Williamson
Subject: Pre-virtualization, was Re: linux/arch/xen/i386 or
linux/arch/i386/xen


On May 18, 2005, at 17:09, Magenheimer, Dan (HP Labs Fort Collins)
wrote:

There have been various discussions on this list about
"transparent paravirtualization", i.e. the ability for
a paravirtualized kernel to run both as a guest of Xen
and on bare metal.  This is definitely an objective of
Xen/ia64.  Nobody has tried it for Xen/x86, but if it
can be done, I'm sure commercial companies and distros
would be eager to utilize it (one less set of bits to
support).



Thanks for the lead-in Dan.  As mentioned before on this list, we
have an automated, pre-virtualization solution that permits a single
binary to execute on bare x86 hardware and on various hypervisors,
with good performance.  See the original message:
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg

00163.html


We have now released our source code.  For our project web page,
source code (BSD license), and a script to build everything, see:
http://l4ka.org/projects/virtualization/afterburn/
We tried to minimize the overhead for getting started, but we can't
automate the parts that are dependent on the final hardware,
and thus
some tenacious debug skills may be necessary.  Also see the user's
manual.

Note that our project does use some concepts of transparent para-
virtualization, primarily to deal with higher-level OS concepts.
Capturing higher-level OS concepts is particularly useful when
mapping guest OS concepts to hypervisor concepts, as is common on
more traditional kernels, such as executing at user-level on Linux,
Windows NT, and our L4 microkernel.  Transparent
virtualization isn't
really used on our internal Xen infrastructure (although in our
public CVS, it is used a little).



In many ways, a "xen" subdirectory is much more like
a "pci" or "math-emu" subdirectory, than a subarch.
For example, mach-es7000 and xen may need to co-exist
in the same kernel.

So, mach-xen may be a poor choice.  A subtle distinction
perhaps but when dealing with Linux kernel developers,
purity of thinking may avoid future patch submission
arguments.


With pre-virtualization, the modifications to the guest OS are very
minor.  The whole point is to automate the para-virtualization.  So
for example, a single binary can execute on the Xen
hypervisor, or as
a user-level Linux application, without using any of the user-mode
Linux support currently in Linux, and without requiring the proposed
additions to Linux for Xen.

-Josh







_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.