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] Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
From: Andrew Lutomirski <luto@xxxxxxx>
Date: Wed, 27 Jul 2011 13:05:18 -0400
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, keir.xen@xxxxxxxxx
Delivery-date: Wed, 27 Jul 2011 10:12:19 -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=bM2o3SfH71jewFYItEwf8EgZMtOFoMW384BYGaZ5JeI=; b=I7Zjid9QlbPWqs9g84pApsoFULspE7W8QxiMwBkzB7d/G0Lqg9L1EcP4RsGnpWowIu O9cMIwkTtLgmQRKY9fqFDyd7aBsopXMrf5a5bzzTMN9sveXapciHYng0S32Ee8ls7mfh ZdmzUNhQ3ir44P6pAyem+T+BZQmqHEKI3HBpk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110727165844.GA8064@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: <cover.1311736366.git.luto@xxxxxxx> <20110727145745.GA11872@xxxxxxxxxxxx> <CAObL_7FT8QLg-wihasBahhAtS=pA7+KeU8E=E9x8NPZ0+QJ5iQ@xxxxxxxxxxxxxx> <20110727153015.GA16688@xxxxxxxxxxxx> <CAObL_7GWGx4rYJFLpucEX=ozNpk+5ipyq0=vw16xcGetEXSuGQ@xxxxxxxxxxxxxx> <20110727154316.GA16909@xxxxxxxxxxxx> <CAObL_7FncQ7DdNf2igFZW=ZzPFQLO3Vvp1c_y5EajA_KTt8iOg@xxxxxxxxxxxxxx> <20110727165844.GA8064@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Jul 27, 2011 at 12:58 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
>> >> $ test_vsyscall test
>> >> Testing gettimeofday...
>> >>   vDSO offset = 0.000001s
>> >>   vsyscall offset = 0.000001s
>> >>
>> >> Testing time...
>> >>   vDSO offset = 0
>> >>   vsyscall offset = 0
>> >> Testing getcpu...
>> >>   ok!  cpu=6 node=0
>> I bet if you pull a new copy or remove -mavx from Makefile it will
>> work.  I got a grossly hacked-up Xen domU booted and everything seems
>> to work.
> It did. Both Dom0 and DomU work on AMD and Intel.
> In regards to the last pv-ops patch - is there no better way? The reason I am 
> asking
> is the pv-ops hook is just a bandaid for the problem. Is the Xen syscall 
> suppose to
> be doingsomething extra with the stack perhaps?

The Xen code in question is:

        testw $TRAP_syscall,4(%rsp)
        jz    iret_exit_to_guest

        addq  $8,%rsp
        popq  %rcx                    # RIP
        popq  %r11                    # CS
        cmpw  $FLAT_USER_CS32,%r11
        popq  %r11                    # RFLAGS
        popq  %rsp                    # RSP
        je    1f
1:      sysretl

So with VCGF_in_syscall set, the ireq hypercall will return via
sysretq if the saved CS is __USER_CS or FLAT_USER_CS64.  This is
faster than iretq.

The hypervisor doesn't allow the guest OS to override the values in
MSR_STAR, so FLAT_USER_CS64 gets returned to userspace.  And sysretq
is probably much faster than iretq, so unsetting VCGF_in_syscall is
probably a bad idea.

The ideal solution would be to allow the kernel to change MSR_STAR,
but this would require changing the hypervisor and the kernel.


Xen-devel mailing list