From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzJRu-00036B-0L for qemu-devel@nongnu.org; Sat, 17 Oct 2009 20:16:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzJRr-00035q-Qk for qemu-devel@nongnu.org; Sat, 17 Oct 2009 20:16:36 -0400 Received: from [199.232.76.173] (port=53557 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzJRr-00035n-JM for qemu-devel@nongnu.org; Sat, 17 Oct 2009 20:16:35 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:6249) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzJRr-0005aj-79 for qemu-devel@nongnu.org; Sat, 17 Oct 2009 20:16:35 -0400 Received: by fg-out-1718.google.com with SMTP id 16so11404fgg.10 for ; Sat, 17 Oct 2009 17:16:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20091017195726.GB9922@laped.iglesias.mooo.com> References: <761ea48b0907110814t12c644b6mf733d3b5e28e152@mail.gmail.com> <20091017195726.GB9922@laped.iglesias.mooo.com> Date: Sun, 18 Oct 2009 02:16:33 +0200 Message-ID: <761ea48b0910171716p1243c63cqac0f8a4085f84c9b@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: qemu-devel@nongnu.org Hi Edgar, On Sat, Oct 17, 2009 at 9:57 PM, Edgar E. Iglesias wrote: > > It feels a bit strange to have the CPU model know about linux vsyscalls. > Did you consider having the linux-user loader pass a qemu version of the > x86_64 vdso to the guest through the auxvector? That version could probably > implement the vsyscalls by translating them into syscalls with x86_64 code. > It probably doesn't even need to do that btw, just make sure to fill it > with syscall insns to raise exceptions and then have the linux-user/ code > treat syscalls with eip from vdso page differently. That way the CPU model > doesn't need to know about vdso and you can implement vsyscalls that may > need magic interactions with qemu. > > Or does that not work for some reason? Performance? > Are there maybe old binaries that don't look in the auxvector and just assume > a fixed address for the vdso? A recent compiler (gcc 4.4.0) produces this code for a statically compiled program: 00000000005779e0