xen-devel
[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
To: |
Chris Wright <chrisw@xxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching |
From: |
Joshua LeVasseur <jtl@xxxxxxxxxx> |
Date: |
Thu, 23 Mar 2006 12:42:45 +0100 |
Cc: |
Zachary Amsden <zach@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx> |
Delivery-date: |
Thu, 23 Mar 2006 18:10:55 +0000 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<20060323010627.GS15997@xxxxxxxxxxxxxxxxxx> |
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: |
<200603131802.k2DI2nv8005665@xxxxxxxxxxxxxxxxxxx> <200603222115.46926.ak@xxxxxxx> <20060322214025.GJ15997@xxxxxxxxxxxxxxxxxx> <4421CCA8.4080702@xxxxxxxxxx> <20060322225117.GM15997@xxxxxxxxxxxxxxxxxx> <4421DF62.8020903@xxxxxxxxxx> <20060323004136.GR15997@xxxxxxxxxxxxxxxxxx> <4421F1AD.1070108@xxxxxxxxxx> <20060323010627.GS15997@xxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Mar 23, 2006, at 02:06 , Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) wrote:
No, you don't need to dream up all the possible interface bits
ahead of
time. With a la carte interfaces, you can take what you need now,
and
add features later. You don't need an ABI for features. You need it
for compatibility. You will need to update the hypervisor ABI.
And you
can't force people to upgrade their kernels.
How do you support an interface that's not already a part of the ABI
w/out changing the kernel?
Since the base ABI primarily consists of the x86's privileged
instruction set (actually, the virtualization-sensitive instructions,
and padded with NOP instructions), any ROM can work from there, and
you don't have to worry about updating Linux to use a new ABI. If
you use a new ROM+ABI with an old kernel+ABI, they can fall back to
the base ABI. Note that this base ABI isn't arbitrary; it wasn't
pulled out of thin air; it is mostly the x86 system ISA.
If an updated hypervisor offers new features that didn't exist when a
particular Linux kernel was written and compiled, a new ROM has a
very good chance of activating those new features, even if only using
the base ABI of the older Linux kernel. The ROM is very versatile
because it maps the low-level instructions to high-level hypervisor
concepts. And it is very successful: I have built a Linux 2.6.9
binary and executed it on Xen 2.0.2, Xen 2.0.7, and Xen 3.0.1; I have
also built a Linux 2.6.12.6 binary and executed it on Xen 2.0.2, Xen
2.0.7, and Xen 3.0.1. This is significant because XenoLinux 2.6.9
shipped with Xen 2.0.2 and it doesn't work on Xen 3.0.1 due to many
interface updates; likewise XenoLinux 2.6.12.6 shipped with Xen 3.0.1
and it doesn't work on the older Xen 2 hypervisors; but the ROM hid
the interface updates from Xen 2 series to the Xen 3 series, and it
takes advantage of the new Xen 3 interfaces (it must since Xen 3
doesn't have a Xen 2 compatibility layer that I'm aware of).
The ROM's interface mapping solves two problems: it converts the x86
low-level instructions into high-performance hypervisor operations,
and it maps the low-level instructions into the hypervisor's evolving
interface. The ROM gives great independence for hypervisor
developers, or in other words, permits proliferation of hypervisors,
and freedom to experiment with interfaces (e.g., real time, or formal
verification).
Joshua
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, (continued)
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Chris Wright
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Zachary Amsden
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Chris Wright
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Zachary Amsden
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Chris Wright
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching, Zachary Amsden
- [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching,
Joshua LeVasseur <=
|
|
|