On Sun, 7 Feb 2010, Richard Henderson wrote:
>
> 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 wo
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
difficult.
Actually, it should
On Sun, Feb 7, 2010 at 1:22 AM, Jamie Lokier wrote:
[...]
>>
>> 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
On Sun, 7 Feb 2010, Jamie Lokier wrote:
> Laurent Desnogues wrote:
> > On Sat, Feb 6, 2010 at 8:49 AM, Stefan Weil 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 alway
Laurent Desnogues wrote:
> On Sat, Feb 6, 2010 at 8:49 AM, Stefan Weil 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
On Sat, Feb 6, 2010 at 8:49 AM, Stefan Weil 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
>
>
On 02/05/2010 02:57 PM, Stefan Weil wrote:
I tried to modify x86_64-linux-user to set up a vsyscall page in high
memory, but this seems to be difficult (at least with 32 bit host).
A 64-bit userland guest can only use the low 32-bits of its address
space with a 32-bit host at the moment. If y
Laurent Desnogues schrieb:
> On Fri, Feb 5, 2010 at 11:57 PM, Stefan Weil wrote:
>> Laurent Desnogues schrieb:
> [...]
>> I'm still struggling with bntest and other x86_64-linux-user software
>> calling any of the vsyscall functions.
>>
>> Laurent, your vsyscall patch only works on x86_64 hosts.
>
On Fri, Feb 5, 2010 at 11:57 PM, Stefan Weil wrote:
> Laurent Desnogues schrieb:
[...]
>
> I'm still struggling with bntest and other x86_64-linux-user software
> calling any of the vsyscall functions.
>
> Laurent, your vsyscall patch only works on x86_64 hosts.
>
> A lot of software calls time()
Laurent Desnogues schrieb:
> On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote:
> [...]
>> 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.
>
Laurent Desnogues schrieb:
> On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote:
> [...]
>> 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.
>
On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote:
[...]
>
> 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
On Sun, Oct 18, 2009 at 4:47 AM, Jamie Lokier wrote:
> Laurent Desnogues wrote:
>> A recent compiler (gcc 4.4.0) produces this code for a statically
>> compiled program:
>>
>> 005779e0 :
>> 5779e0: 48 83 ec 08 sub $0x8,%rsp
>> 5779e4: 48 c7 c0 00 04 60 ff mov
On Sun, Oct 18, 2009 at 04:09:44AM +0100, Jamie Lokier wrote:
> 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
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
Laurent Desnogues wrote:
> A recent compiler (gcc 4.4.0) produces this code for a statically
> compiled program:
>
> 005779e0 :
> 5779e0: 48 83 ec 08 sub$0x8,%rsp
> 5779e4: 48 c7 c0 00 04 60 ffmov$0xff600400,%rax
> 5779eb: ff d0
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
On Sat, Jul 11, 2009 at 05:14:47PM +0200, Laurent Desnogues wrote:
> Hello,
>
> the attached patch implements two of the three x86_64 vsyscall's.
> Also attached is a test that demonstrates the issue and hopefully
> the fix.
>
> Note there is a trick in there: since vsyscall functions are in hig
18 matches
Mail list logo
