|
xen-devel
[Xen-devel] Re: A proposal - binary
|
To: |
Antonio Vargas <windenntw@xxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: A proposal - binary |
|
From: |
Chris Wright <chrisw@xxxxxxxxxxxx> |
|
Date: |
Fri, 4 Aug 2006 00:01:42 -0700 |
|
Cc: |
Andrew Morton <akpm@xxxxxxxx>, zach@xxxxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>, simon@xxxxxxxxxxxxx, hch@xxxxxxxxxxxxx, jlo@xxxxxxxxxx, greg@xxxxxxxxx, rusty@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, ian.pratt@xxxxxxxxxxxxx, torvalds@xxxxxxxx |
|
Delivery-date: |
Fri, 04 Aug 2006 00:00:39 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<69304d110608032328r36bc0a6ase0a2dbf36d8cc519@xxxxxxxxxxxxxx> |
|
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: |
<44D1CC7D.4010600@xxxxxxxxxx> <20060803190605.GB14237@xxxxxxxxx> <44D24DD8.1080006@xxxxxxxxxx> <20060803200136.GB28537@xxxxxxxxx> <44D2B678.6060400@xxxxxxxxxxxxx> <20060803211850.3a01d0cc.akpm@xxxxxxxx> <20060804054002.GC11244@xxxxxxxxxxxxxxxxxxxx> <69304d110608032328r36bc0a6ase0a2dbf36d8cc519@xxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mutt/1.4.2.1i |
* Antonio Vargas (windenntw@xxxxxxxxx) wrote:
> One feature I found missing at the paravirt patches is to allow the
> user to forbid the use of paravirtualization of certain features (via
> a bitmask on the kernel commandline for example) so that the execution
> drops into the native hardware virtualization system. Such a feature
There is no native harware virtualization system in this picture. Maybe
I'm just misunderstanding you.
> would provide a big upwards compatibility for the kernel<->hypervisor
> system. The case for this would be needing to forcefully upgrade the
> hypervisor due to security issues and finding out that the hypervisor
> is incompatible at the paravirtualizatrion level, then the user would
> be at least capable of continuing to run the old kernel with the new
> hypervisor until the compatibility is reached again.
This seems a bit like a trumped up example, as randomly disabling a part
of the pv interface is likely to cause correctness issues, not just
performance degradation.
Hypervisor compatibility is a slightly separate issue here. There's two
interfaces. The linux paravirt interface is internal to the kernel.
The hypervisor interface is external to the kernel.
kernel <--pv interface--> paravirt glue layer <--hv interface--> hypervisor
So changes to the hypervisor must remain ABI compatible to continue
working with the same kernel. This is the same requirement the kernel
has with the syscall interface it provides to userspace.
> BTW, what is the recommended distro or kernel setup to help testing
> the latest paravirt patches? I've got a spare machine (with no needed
> data) at hand which could be put to good use.
Distro of choice. Current kernel with the pv patches[1], but be
forewarned, they are very early, and not fully booting.
thanks,
-chris
[1] mercurial patchqueue http://ozlabs.org/~rusty/paravirt/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home