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: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] Automated para-virtualization
From: Joshua LeVasseur <jtl@xxxxxxxxxx>
Date: Wed, 6 Apr 2005 17:08:48 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 06 Apr 2005 15:07:51 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42535DFA.10006@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: <E1DIxxR-0007GW-TE@host-192-168-0-1-bcn-london> <42535DFA.10006@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Hi Anthony,

On Apr 6, 2005, at 05:56, Anthony Liguori wrote:
Very interesting...

Thanks for the good questions and interest.


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?

We annotate both, but in different annotation domains. We apply the annotations for performance, especially the mmio annotations. The page table references aren't as critical in many work loads, but if page table activity is expected, then it is probably a necessary optimization.

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

This is true. It would be possible to avoid the annotations, and to instead rely on traps. Although we prefer to automate these annotations, which is currently our active work. And additionally, it is possible to avoid heavy trapping on the page tables by tracking page table accesses with the reference bits.

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?

Probably ... we don't handle 16-bit code right now, so the CROSS_COMPILE solution needs a little work to avoid annotating the 16-bit code. The implication is that the current solution jumps to the 32-bit entry point, and relies on the runtime module preparing "physical" memory with all the guest-specific boot loader information (I guess that this is the "start of day" in Xen terminology).

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?

Either solution works ... just an implementation (or user interface/management) issue.

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

Yes, modules must be supported long term. Modules need to be annotated, and then patched at load time, thus probably requiring collaboration from the OS to announce the installation of a new module. The implication is that 3rd party modules benefit from automated para-virtualization.

Have you implemented any other emulated devices?

Basic platform devices. We're working on high performance disk, and the IO-APIC. Port I/O is particularly nice and easy, especially for ports <= 0xff, and thus the XT-PIC emulation is subject to nice rewriting.

Great! Look forward to seeing the code. Looks like you guys have been doing really cool stuff :-)

Thanks,
Josh


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

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