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/
Home Products Support Community News


[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:37:54 -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:36:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <69304d110608040019i2f68518dq4e84a96a8787b0eb@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> <20060804070142.GW2654@xxxxxxxxxxxxxxxxxxxx> <69304d110608040019i2f68518dq4e84a96a8787b0eb@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
* Antonio Vargas (windenntw@xxxxxxxxx) wrote:
> What I was refering with "native hardware virtualization" is just the
> VT or Pacitifica -provided trapping into the hypervisor upon executing
> "dangerous" instructions such as tlb-flushes, reading/setting the
> current ring-level, cli/sti...

We are not talking about VMX or AMDV.  Just plain ol' x86 hardware.

> Yes, maybe just providing a switch to force paravirtops to use the
> native hardware implementation would be enough, or just in case,
> making the default the native hardware and allowing the kernel
> commandline to select another one (just like on io-schedulers)

In this case native hardware == running on bare metal w/out VMX/AMDV
support and w/out any hypervisor.  So, while this would let you actually
boot the machine, it's probably not really useful for the case you cited
(security update to hypervisor causes ABI breakage) because you'd be
booting a normal kernel w/out any virtualization.  IOW, all the virtual
machines that were running on that physical machine would not be running.

> Yes. What I propose is allowing the systems to continue running (only
> with degraded performance) when the hv-interface between the running
> kernel and the running hypervisor doesn't match.

This is non-trivial.  If the hv-interface breaks the ABI, then you'd
need to update the pv-glue layer in the kernel.

> >> 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, will be setting it up :)

Thanks for helping.

Xen-devel mailing list

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