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: Keir Fraser <keir.xen@xxxxxxxxx>
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: Tue, 26 Jul 2011 17:10:53 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 26 Jul 2011 14:11:44 -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=cfviLYlqKX/HrLQCBthwlhWdw2w6f8H36qT73/yn8X4=; b=kWJxQCiIUjLWR5eY+aqR+ZD7wrDrRAMVxqZWiXUrn5oyX/il+ufwUrtC1c78yMB8Th 3HPeHYm8529EQ6oJmmLbhehWTEuC5GccJwBoV5L9O1JKGK1XURfX7bjzMLR4YND9wBMR lKxj9NFQ74ueQa6c1uUqCGNnjUdLOuqS3Q08M=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA54E6A4.1E91B%keir.xen@xxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Jul 26, 2011 at 4:48 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 26/07/2011 20:08, "Andrew Lutomirski" <luto@xxxxxxx> wrote:
>> On Tue, Jul 26, 2011 at 11:32 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@xxxxxxxxxx> wrote:
>>> On Mon, Jul 25, 2011 at 09:50:30PM -0400, Andrew Lutomirski wrote:
>>>> After staring at the Xen assembly code with vague comprehension, I
>>>> think I can sort of understand what's going on.
>>> Ok.
>>>> Can you run this little program on a working kernel and tell me what
>>>> it says (built as 64-bit and as 32-bit (with -m32)):
>>> 32-bit:
>>> [konrad@f13-x86-build ~]$ ./check
>>> cs = 73
>>> [konrad@f13-x86-build ~]$ uname -a
>>> Linux f13-x86-build.dumpdata.com 3.0.0 #1 SMP PREEMPT Tue Jul 26 09:56:38 
>>> EDT
>>> 2011 i686 i686 i386 GNU/Linux
>>> 64-bit:
>>> [konrad@f13-amd64-build ~]$ ./check
>>> cs = e033
>> My best guess is that each task starts out with standard __USER_CS,
>> but the code in write_stack_trampoline (in the hypervisor) tells the
>> kernel that CS is 0xe033 and then the next return to userspace makes
>> it true.
> Yes, that's right.

But it's still weird, because AFAICT xen_sysret64 already does the
right thing.  So presumably the failure case only happens when
something prevents sysret from working, like CONFIG_AUDITSYSCALL.

>> I'll hack up a patch to avoid the crash.  I'll feel better about it if
>> you or any of the Xen gurus can confirm that explanation.  If I'm
>> right, I need to check for both __USER_CS and FLAT_RING3_CS.
> Either that, or Linux needs to poke its preferred 32- or 64-bit user CS
> value into the return stackframe when it receives a syscall notification
> from Xen.

That sounds simpler.  It will also make Xen userspace look more like
native userspace.


>  -- Keir
>> --Andy
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel

Xen-devel mailing list

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