WARNING - OLD ARCHIVES

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

xen-devel

[Xen-devel] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: [Xen-devel] 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 15:01:17 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, andi@xxxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, richard.weinberger@xxxxxxxxx, brgerst@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, JBeulich@xxxxxxxxxx, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Louis.Rilling@xxxxxxxxxxx, jj@xxxxxxxxxxxxx, mikpe@xxxxxxxx, Valdis.Kletnieks@xxxxxx, mingo@xxxxxxx, pageexec@xxxxxxxxxxx, arjan@xxxxxxxxxxxxx
Delivery-date: Tue, 26 Jul 2011 12:02:24 -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; bh=ja1lsiYf7UIRWw+ENqvL6bytPV1eqhIWmmUDvRH/UKA=; b=oN9pkTW7LVdeYCme9iFJw2/ApDTPRJ82bzaRE5aaSQywFUAEf05DjvzRlX7+d3adB9 Tq3cI6hQhcFtl+h+SIH5baHYw7MW/+tBmCNAPnbHgi3Z5zxNYExcVYJen/CAmZTh4tdj tCGnHDBSJVzcm8bmxDS8ZhW+za9Ux8nJFu1KE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110726161808.GA5333@xxxxxxxxxxxx>
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: <20110725155442.GA21759@xxxxxxxxxxxx> <20110725161009.GA9193@xxxxxxxxxxxx> <CAObL_7F9+Wn1DBf5te7BHoAe3CbEzR=pxTqy_S_vpkwcG57NKQ@xxxxxxxxxxxxxx> <20110726161808.GA5333@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Jul 26, 2011 at 12:18 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
>> > However, this is what I get later on, any ideas?
>>
>> > [    0.585880] init[1] illegal int 0xcc from 32-bit mode 
>> > ip:ffffffffff600400 cs:e033 sp:7fff230ca088 ax:ffffffffff600400 
>> > si:7faee3e822bf di:7fff230ca158
>>
>> That will, indeed, crash your system.
>>
>> 0xe033 is FLAT_RING3_CS64
>>
>> Jeremy / other Xen people:  I'm trying to implement a lightweight
>> check to distinguish a trap from a sane (i.e. allowable for syscalls)
>> 64-bit user context from anything else.  There seems to be precedent
>> for using ->cs == __USER_CS to detect 64-bitness; for example, step.c
>> contains:
>>
>> #ifdef CONFIG_X86_64
>>                 case 0x40 ... 0x4f:
>>                         if (regs->cs != __USER_CS)
>>                                 /* 32-bit mode: register increment */
>>                                 return 0;
>>                         /* 64-bit mode: REX prefix */
>>                         continue;
>> #endif
>>
>> The prefetch opcode checker in mm/fault.c does something similar.
>>
>> Even the sysret code in xen/xen-asm_64.S does:
>>
>>         pushq %r11
>>         pushq $__USER_CS
>>         pushq %rcx
>>
>> So I'm at a bit of a loss.
>>
>> You could probably hack it up and get your kernel to boot by allowing
>> __USER_CS and 0xe033 in that check, but I'd rather understand it
>
> Did this little hack:
>
>
> diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
> index dda7dff..5d0cf37 100644
> --- a/arch/x86/kernel/vsyscall_64.c
> +++ b/arch/x86/kernel/vsyscall_64.c
> @@ -131,7 +131,7 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs 
> *regs, long error_code)
>         * Real 64-bit user mode code has cs == __USER_CS.  Anything else
>         * is bogus.
>         */
> -       if (regs->cs != __USER_CS) {
> +       if ((regs->cs != __USER_CS) && (regs->cs != FLAT_RING3_CS64)) {
>                /*
>                 * If we trapped from kernel mode, we might as well OOPS now
>                 * instead of returning to some random address and OOPSing
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index f987bde..0e4c13c 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1916,6 +1916,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t 
> phys, pgprot_t prot)
>  # endif
>  #else
>        case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
> +       case VVAR_PAGE:
>  #endif
>        case FIX_TEXT_POKE0:
>        case FIX_TEXT_POKE1:
>
> And getting this on 64-bit:
>
>  started: BusyBox v1.14.3 (2011-07-26 11:43:49 EDT)
> [    0.578603] rcS[1128]: segfault at ffffffffff5ff0a0 ip 00007fff40b7380a sp 
> 00007fff40b5c0f0 error 4
> [    0.578847] rcS used greatest stack depth: 5024 bytes left
> [    0.581897] sh[1131]: segfault at ffffffffff5ff0a0 ip 00007fffb93ff80a sp 
> 00007fffb92bbd70 error 4
> [    1.587637] sh[1137]: segfault at ffffffffff5ff0a0 ip 00007ffffa5ff80a sp 
> 00007ffffa522560 error 4
> [    2.592295] sh[1141]: segfault at ffffffffff5ff0a0 ip 00007ffffcb3f80a sp 
> 00007ffffca98af0 error 4
> [    3.596344] sh[1145]: segfault at ffffffffff5ff0a0 ip 00007fff2e3ff80a sp 
> 00007fff2e3e3370 error 4
> [    4.599812] sh[1149]: segfault at ffffffffff5ff0a0 ip 00007fff62dff80a sp 
> 00007fff62ca9f10 error 4
> [    5.605835] sh[1153]: segfault at ffffffffff5ff0a0 ip 00007fff117ff80a sp 
> 00007fff1175e7f0 error 4
> [    6.609438] sh[1157]: segfault at ffffffffff5ff0a0 ip 00007fff91bff80a sp 
> 00007fff91bd71c0 error 4
> [    7.614714] sh[1161]: segfault at ffffffffff5ff0a0 ip 00007fff396b280a sp 
> 00007fff3968ede0 error 4
> [    8.620374] sh[1165]: segfault at ffffffffff5ff0a0 ip 00007fffd398b80a sp 
> 00007fffd38ecd70 error 4
> [    9.625512] sh[1169]: segfault at ffffffffff5ff0a0 ip 00007fff617d980a sp 
> 00007fff61776070 error 4
> [   10.630246] sh[1173]: segfault at ffffffffff5ff0a0 ip 00007fff89fff80a sp 
> 00007fff89f7f3b0 error 4
> [   11.635588] sh[1177]: segfault at ffffffffff5ff0a0 ip 00007fffa95ff80a sp 
> 00007fffa95ea7c0 error 4
> [   12.640491] sh[1181]: segfault at ffffffffff5ff0a0 ip 00007fff28cd180a sp 
> 00007fff28c524f0 error 4

That one means that the vvar fixmap isn't working.  Can you try the
attached patch?

--Andy

>
> ..
>

Attachment: xen-hack.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>