[Top][All Lists]

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

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

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Date: Sun, 07 Feb 2010 15:18:10 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

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

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.


reply via email to

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