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] Automated para-virtualization

To: Joshua LeVasseur <jtl@xxxxxxxxxx>
Subject: Re: [Xen-devel] Automated para-virtualization
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 05 Apr 2005 22:56:42 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 06 Apr 2005 04:00:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E1DIxxR-0007GW-TE@host-192-168-0-1-bcn-london>
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>
Organization: IBM
References: <E1DIxxR-0007GW-TE@host-192-168-0-1-bcn-london>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Joshua LeVasseur wrote:

Hello,
Hi Joshua,

We, University of Karlsruhe and UNSW/NICTA, have been working on a technique
to automate para-virtualization, in the hopes of simplifying the maintenance
of the various guest OSs, and would like to share our results to date.
Very interesting...

The basis of our solution is instruction substitution at the assembler level
in order to replace the virtualization-sensitive operations of the guest OS.
The virtualization-sensitive operations include instructions and memory
accesses (such as to page tables or device registers).
So you annotate access to mmio or page tables? Was this for performance or was it not possible to emulate mmio operations and trap writes to the page table?

If you were able to avoid having to annotate these things, I presume you could virtualize Linux with no modifications? Even if this resulted in performance degradation, I can imagine scenarios where having this option would be very useful (especially for supporting legacy distributions).

annotations).  There are a few additional changes for the build process.
Would it be possible to package your tools as a cross-compiler environment so that all you had to do is set CROSS_COMPILE appropriately?

Our current research is to enable run-time migrations between incompatible
hypervisors, or between different versions of the same hypervisor, by
rewriting the instruction substitutions at time of migration.  Additionally,
we envisage that one can install a hypervisor underneath an OS which runs on
bare metal.
Does this mean that you maintain the patch table and support unpatching a patched image or do you simply keep a copy of the unpatched kernel?

Any thoughts on supporting kernel modules? Would you have to prepatch a module?

We have a high speed network device emulation, for the DP83820 driver, based
on the sensitive memory instruction substitution (an additional several line
patch to enable manual annotations).  If the guest OS uses the DP83820
device, then it has high-speed access to devices running in Dom0.  The speed
is comparable to using a customized device driver.  By using the DP83820
device, a guest OS can migrate between different hypervisors, since the
state is encapsulated in a model, and not a driver.
Have you implemented any other emulated devices?

We will shortly release the code under a BSD license.
Great! Look forward to seeing the code. Looks like you guys have been doing really 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>