From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeGOP-0004fS-Og for qemu-devel@nongnu.org; Sun, 07 Feb 2010 18:18:17 -0500 Received: from [199.232.76.173] (port=44849 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeGOP-0004fC-FL for qemu-devel@nongnu.org; Sun, 07 Feb 2010 18:18:17 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeGOO-0003vU-Js for qemu-devel@nongnu.org; Sun, 07 Feb 2010 18:18:17 -0500 Received: from mx20.gnu.org ([199.232.41.8]:54697) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NeGOO-0003uB-C4 for qemu-devel@nongnu.org; Sun, 07 Feb 2010 18:18:16 -0500 Received: from are.twiddle.net ([75.149.56.221]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NeGOM-0006Gz-Nw for qemu-devel@nongnu.org; Sun, 07 Feb 2010 18:18:14 -0500 Message-ID: <4B6F4A32.8070204@twiddle.net> Date: Sun, 07 Feb 2010 15:18:10 -0800 From: Richard Henderson 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> <4B6CA26C.3060106@mail.berlios.de> <761ea48b1002051737k6d6d33a5pbdcdf0e2527988c1@mail.gmail.com> <4B6D1F17.7020904@mail.berlios.de> <761ea48b1002061550o54a940bfo438fb5f052c5e06e@mail.gmail.com> In-Reply-To: <761ea48b1002061550o54a940bfo438fb5f052c5e06e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: qemu-devel@nongnu.org On 02/06/2010 03:50 PM, Laurent Desnogues wrote: >> * target-i386 code should not have to know about >> linux vsyscall > > Given that we have to workaround 64-bit virtual > address limitations (cf. Richard mail and previous > discussions on the list), doing otherwise looks > difficult. Actually, it should be easy for QEMU to handle this. The application is given the address of the VDSO in the AT_SYSINFO and AT_SYSINFO_EHDR entries of the auxvec (on the stack above argv and environ). We can place this anywhere we like; the fact that the kernel puts it in high memory is merely a convenience to the kernel. There *is* a legacy vsyscall address in high memory, from before the whole VDSO arrangement was worked out, but we could probably get away with ignoring that. Certainly well behaved applications will be honoring the VDSO when it is given. >> * it is not possible to step into vsyscall code >> using a debugger > > How would you achieve that? Your guest OS > doesn't necessarily have the code mapped. I > think this has to be considered as other syscalls, > though slightly different. If QEMU implements the VDSO, the page *will* be mapped, and the debugger will Just Work. I imagine that QEMU's VDSO would not have the complicated bits that the kernel's version does, where it arranges to read the clock without going into kernel space. I imagine QEMU would simply stuff a normal syscall sequence in there, which would automatically be emulated in the normal way. Have a stare at the linux/arch/x86/vdso directory to see how things work. r~