WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Joshua LeVasseur <jtl@xxxxxxxxxx>
Subject: Re: [Xen-devel] Pre-virtualization, was Re: linux/arch/xen/i386 or linux/arch/i386/xen
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Fri, 20 May 2005 13:52:03 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 20 May 2005 18:51:37 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2F399538-FA23-47CC-9516-52899143BF33@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <2F399538-FA23-47CC-9516-52899143BF33@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
Joshua LeVasseur wrote:

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/msg00163.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).

Hi Joshua,

After looking through the code I have a couple of questions/comments.

1) I noticed that you have a patch to xen-2.0.2. One of the changes was a known gcc bug that's been worked around in newer versions of 2.0.x. The other changes explicitly disabled SMP and ACPI. Is there a compelling reason to patch xen for this verses just specifying the appropriate command line options to disable these things at run time?

2) The Linux guest changes seem a big more substantial than I expected. Is there a place where you break down what these changes were and why the were necessary? Do you have any idea of the additional amount of work necessary to reduce these changes to as small as humanly possible (perhaps even no changes at all)?

Very cool stuff.

Regards,

Anthony Liguori

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

<Prev in Thread] Current Thread [Next in Thread>