From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NdX8N-0006wP-4p for qemu-devel@nongnu.org; Fri, 05 Feb 2010 17:58:43 -0500 Received: from [199.232.76.173] (port=52867 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdX8M-0006wD-B0 for qemu-devel@nongnu.org; Fri, 05 Feb 2010 17:58:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NdX8K-0005K9-FW for qemu-devel@nongnu.org; Fri, 05 Feb 2010 17:58:42 -0500 Received: from mx20.gnu.org ([199.232.41.8]:30198) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NdX8K-0005Jo-6X for qemu-devel@nongnu.org; Fri, 05 Feb 2010 17:58:40 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NdX8J-0006A3-7X for qemu-devel@nongnu.org; Fri, 05 Feb 2010 17:58:39 -0500 Message-ID: <4B6CA26C.3060106@mail.berlios.de> Date: Fri, 05 Feb 2010 23:57:48 +0100 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall References: <761ea48b0907110814t12c644b6mf733d3b5e28e152@mail.gmail.com> <20091017195726.GB9922@laped.iglesias.mooo.com> <20091018030944.GB15656@shareable.org> <761ea48b0910180429l9fdf32r7f0a8f7ceebb9eee@mail.gmail.com> In-Reply-To: <761ea48b0910180429l9fdf32r7f0a8f7ceebb9eee@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: "Edgar E. Iglesias" , qemu-devel@nongnu.org Laurent Desnogues schrieb: > On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote: > [...] >> Please don't do that. Some code traces instructions through the >> vsyscall/vdso page, and will be surprised if a syscall instruction >> does not do what's expected based on the registers at that point. >> >> Also I don't know if anyone's done this, but I have played with the >> idea of an optimising x86->x86 JIT translator (similar to valgrind or >> qemu's TCG) which would include the vdso instruction sequence in it's >> traces, just because it didn't treat that any differently from other >> userspace code. Making the syscall instruction behave differently due >> to EIP would break that sort of thing. >> >> There's no performance penalty in setting a few registers prior to >> using the syscall instruction normally, so please do that. > > My proposed patch intercepts vsyscall as soon as the PC is > in the [VSYSCALL_START, VSYSCALL_END[ range, so all > instructions in that range won't be translated. Doing it > differently will cause problems due to the virtual address. > >> On x86_64, the vsyscall page has fixed address (see >> linux/arch/x86/kernel/vsyscall_64.c), but the vdso usually has >> variable address. >> >> On x86_32, the vdso has randomised address unless configurd to be a >> fixed address. On older kernels it was a fixed address and some >> binary programs assume they can call that. > > So QEMU can't do things properly and some binaries will > fail, right? > > > Laurent I'm still struggling with bntest and other x86_64-linux-user software calling any of the vsyscall functions. Laurent, your vsyscall patch only works on x86_64 hosts. A lot of software calls time() which uses vsyscall on x86_64 which does not work with x86_64-linux-user mode. So the status of x86_64-linux-user is not more than experimental :-( I tried to modify x86_64-linux-user to set up a vsyscall page in high memory, but this seems to be difficult (at least with 32 bit host). Any hints how this should be done are welcome. Stefan