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


Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed07

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).
From: Andrew Lutomirski <luto@xxxxxxx>
Date: Thu, 28 Jul 2011 00:33:33 -0400
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 27 Jul 2011 21:34:35 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=bHGnvWc81ep+BNLJUCO/2qqFyMrbVGkfb3EnmRcGiH4=; b=A1ceBJmaptweBore8mNrXCvv8UjxGoXTcb2VgJ+f9Om6rMLx9gpfxKbMLb0at8YCHt zzhN+xK0EcqegE8zKxQzO7ytWPObjQRf6+SUCx/D7OT67c9TurpZq0d/xxOb7hPN5wHV MFvMM69F3NcqF7Hb2QaoBJgtbzjrd2o66BeEY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E3048B4.6020805@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAObL_7HYJLN3Eq2Q4ESuU4=4230Xs37C6Jqn1OYApr2LXTvo3Q@xxxxxxxxxxxxxx> <CA54E6A4.1E91B%keir.xen@xxxxxxxxx> <CAObL_7G31QbwkRdmzf8ABFTmsKbmca=KPkQNM2J_jgT6VG6JqQ@xxxxxxxxxxxxxx> <CAObL_7Emqw0wg1pkvgYQBF7uPm5xCjFUpWsTso61-WRSoCtFzQ@xxxxxxxxxxxxxx> <1093cd3a-acfe-49ab-b410-9fb49b139816@xxxxxxxxxxxxxxxxx> <CAObL_7E1g_PqongTRm-Hve7ERurPtUh+JAj+1JGOTeOLK9mz4A@xxxxxxxxxxxxxx> <4E30317E.30706@xxxxxxxx> <CAObL_7FWi-kK0rK2m8OwTUEQtPZQZ0iP88A8WSkb4CNdu2YqLQ@xxxxxxxxxxxxxx> <4E3048B4.6020805@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Jul 27, 2011 at 1:19 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/27/2011 09:02 AM, Andrew Lutomirski wrote:
>> My current patch adds a field to pv_info.  I agree it's ugly.
> Hm, that's not so bad as actually adding a new op though.
>> How terrible would it be to stop using VCGF_in_syscall so we can keep
>> __USER_CS?  Is there a real performance advantage to VCGF_in_syscall?
> I don't know.  64-bit PV guests are already pretty horrid because of all
> the pagetable switching, so it may be that iret vs sysret disappears in
> the wash.  It's certainly a cleaner fix, but I would want to measure it
> before committing to it.

On Sandy Bridge, a null vsyscall takes 373 ns.  Without
VCGF_in_syscall, it's 457 ns.  The change causes my little test app to
get cs == __USER_CS.

I suspect that Sandy Bridge is just about the worst case.  syscall and
sysret are amazingly fast on Sandy Bridge.


>    J

Xen-devel mailing list

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