All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Date: Sun, 18 Oct 2009 04:09:44 +0100	[thread overview]
Message-ID: <20091018030944.GB15656@shareable.org> (raw)
In-Reply-To: <20091017195726.GB9922@laped.iglesias.mooo.com>

Edgar E. Iglesias wrote:
> 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.

That seems like a good idea.

Note that on x86_64, there is _both_ a vsyscall page at a fixed
address, and a vdso page at a randomised address with different
contents.  Binary programs can call either or both.

On x86_32, there is only a vdso page.  It can be a variable or fixed
address.  To run old binaries (but not so old they don't know about
vsyscall), it needs to be mapped at a fixed address.  Modern kernels
have it mapped at a randomised address, and therefore won't work with
those binaries.

> 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?

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.

> Performance?

syscall insns (sysenter/syscall/int $0x80/vsyscall/vdso) could be
translated to helpers for the exact type of system call if the system
call number is known, saving a little overhead.

> Are there maybe old binaries that don't look in the auxvector and
> just assume a fixed address for the vdso?

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.

-- Jamie

  parent reply	other threads:[~2009-10-18  3:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-11 15:14 [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall Laurent Desnogues
2009-10-17 15:42 ` [Qemu-devel] " Laurent Desnogues
2009-10-17 19:57 ` [Qemu-devel] " Edgar E. Iglesias
2009-10-18  0:16   ` Laurent Desnogues
2009-10-18  2:47     ` Jamie Lokier
2009-10-18 11:23       ` Laurent Desnogues
2009-10-18  3:09   ` Jamie Lokier [this message]
2009-10-18  7:17     ` Edgar E. Iglesias
2009-10-18 11:29     ` Laurent Desnogues
2010-02-04 22:15       ` Stefan Weil
2010-02-05 22:57       ` Stefan Weil
2010-02-06  1:37         ` Laurent Desnogues
2010-02-06  7:49           ` Stefan Weil
2010-02-06 23:50             ` Laurent Desnogues
2010-02-07  0:22               ` Jamie Lokier
2010-02-07  3:11                 ` malc
2010-02-07 10:06                 ` Laurent Desnogues
2010-02-07 23:18               ` Richard Henderson
2010-02-08 14:57                 ` Vince Weaver
2010-02-06 20:12         ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091018030944.GB15656@shareable.org \
    --to=jamie@shareable.org \
    --cc=edgar.iglesias@gmail.com \
    --cc=laurent.desnogues@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.