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

[Joshua LeVasseur <jtl@xxxxxxxxxx>]

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