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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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