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: Wed, 27 Jul 2011 12:02:52 -0400
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 27 Jul 2011 09:07:17 -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=X0U53612zvUbxsd90mEielXsVeiRSXi42+qAfku4c94=; b=xdcDH3rpOhrrZo43Mawc2MvX3DZMSZJWKJPVYPe2vzUw+sqOK03rkaRmZynp6zEkNH EnNHPI7iNyJgKWRht3uTLcLciWIlNGbVOHWlJvpPJ/c26KtUybkpYhXUpx99lhABIqeB 3aHemrMxbqe11oVpKzCE+/m5Nqk66xNxK8E2w=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E30317E.30706@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Jul 27, 2011 at 11:40 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/26/2011 07:17 PM, Andrew Lutomirski wrote:
>> On Tue, Jul 26, 2011 at 7:37 PM, j.fitz.inge@xxxxxxxxx <jeremy@xxxxxxxx> 
>> wrote:
>>> The correct fix is to just look at the cpl in cs and ignore the rest of the
>>> selector.
>> No.  All three of these code paths are trap handlers that are trying
>> to distinguish between 64-bit and 32-bit segments.  The CPL is 3 in
>> either case.
> Oh, hm.
>> It looks like the reason I didn't find the code that it references
>> TRAP_syscall not VCGF_in_syscall.  Yay for grep-unfriendly code.
>> Barring a better idea, I'll implement a new paravirt op.
> Ugh.  I'd really like to avoid that.

My current patch adds a field to pv_info.  I agree it's ugly.

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?


Xen-devel mailing list

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