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
|
Home