From: Jamie Lokier <jamie@shareable.org>
To: Laurent Desnogues <laurent.desnogues@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Date: Sun, 7 Feb 2010 00:22:15 +0000 [thread overview]
Message-ID: <20100207002215.GA19430@shareable.org> (raw)
In-Reply-To: <761ea48b1002061550o54a940bfo438fb5f052c5e06e@mail.gmail.com>
Laurent Desnogues wrote:
> On Sat, Feb 6, 2010 at 8:49 AM, Stefan Weil <weil@mail.berlios.de> wrote:
> [...]
> > I tested two different hosts with x86_64-linux-user:
> >
> > * 32 bit Intel (i386) - does not work with your patch
>
> For me x86_64 on i386 has always failed without
> even calling vsyscall :-)
>
> > * 64 bit AMD (x86_64) - works with your patch
It's a bit worrying that it depends on the host architecture at all.
How well does x86_64-linux-user emulation work on non-x86 hosts?
Does the vsyscall emulation depend only on the hosts's address sixe,
or does it have to be an x86 host to work?
> > * 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.
There is no guest OS when doing -user emulation.
Only qemu.
> > My favorite solution would be a vsyscall page mapped
> > to the correct fixed address and filled with QEMU
> > generated specific code, for example code which calls the
> > normal syscalls to do the work. This would only
> > need modifications for linux-user code.
>
> You mean you'd explicitly put somewhere x86_64
> code that simulates the behaviour of vsyscall?
That seems like a good idea to me.
-- Jamie
next prev parent reply other threads:[~2010-02-07 0:22 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
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 [this message]
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=20100207002215.GA19430@shareable.org \
--to=jamie@shareable.org \
--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.