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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: A proposal - binary
From: "Bill Rugolsky Jr." <brugolsky@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 4 Aug 2006 17:40:39 -0400
Cc: Andrew Morton <akpm@xxxxxxxx>, zach@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, jeremy@xxxxxxxxxxxxx, simon@xxxxxxxxxxxxx, jlo@xxxxxxxxxx, greg@xxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Antonio Vargas <windenntw@xxxxxxxxx>, David Lang <dlang@xxxxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, hch@xxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxxx, torvalds@xxxxxxxx, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Aug 2006 02:24:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44D3BB7C.4000001@xxxxxxxx>
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>
Mail-followup-to: "Bill Rugolsky Jr." <brugolsky@xxxxxxxxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, David Lang <dlang@xxxxxxxxxxxxxxxxxx>, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>, Antonio Vargas <windenntw@xxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, jeremy@xxxxxxxxxxxxx, greg@xxxxxxxxx, zach@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, torvalds@xxxxxxxx, hch@xxxxxxxxxxxxx, jlo@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, simon@xxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxxx
References: <20060803225357.e9ab5de1.akpm@xxxxxxxx> <1154675100.11382.47.camel@xxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.63.0608040944480.18902@xxxxxxxxxxxxxxxxxxx> <69304d110608041146t44077033j9a10ae6aee19a16d@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0608041150360.18862@xxxxxxxxxxxxxxxxxxx> <44D39F73.8000803@xxxxxxxxxxxxxxx> <Pine.LNX.4.63.0608041239430.18862@xxxxxxxxxxxxxxxxxxx> <44D3A9F3.2000000@xxxxxxxx> <Pine.LNX.4.63.0608041325280.18862@xxxxxxxxxxxxxxxxxxx> <44D3BB7C.4000001@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Fri, Aug 04, 2006 at 02:26:20PM -0700, Jeremy Fitzhardinge wrote:
> >I also am missing something here. how can a system be compiled to do 
> >several different things for the same privilaged opcode (including 
> >running that opcode) without turning that area of code into a 
> >performance pig as it checks for each possible hypervisor being present?
> Conceptually, the paravirtops structure is a structure of pointers to 
> functions which get filled in at runtime to support whatever hypervisor 
> we're running over.  But it also has the means to patch inline versions 
> of the appropriate code sequences for performance-critical operations.

Perhaps Ulrich and Jakub should join this discussion, as the whole
thing sounds like a rehash of the userland ld.so + glibc versioned ABI.
glibc has weathered 64-bit LFS changes to open(), SYSENTER, and vdso.

Isn't this discussion entirely analogous (except for the patching of
performance critical sections, perhaps) to taking a binary compiled
against glibc-2.0 back on Linux-2.2 and running it on glibc-2.4 + 2.6.17?
Or OpenSolaris, for that matter?

        Bill Rugolsky

Xen-devel mailing list

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