qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Date: Sun, 18 Oct 2009 04:09:44 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]