[Qemu-devel] Question on pointers in the qemu user space emulation

[Qemu-devel] Question on pointers in the qemu user space emulation

[Erik de Castro Lopo]

Hi all,

I'm currently working on implementing a missing part of a linux-user
syscall. This syscall includes a function pointer for a callback.

If one has a 64 bit user space emulation running on a 32 bit host,
how does one handle the fact that the pointer might be 64 bits?

Does the fact that the 32 bit host con only ever give out 32 bit
addreses to the 64 bit guest just cancel out the possibility of
any problems?

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: [Qemu-devel] Question on pointers in the qemu user space emulation

[Christopher Covington]

Hi Erik,

On 01/17/2014 01:33 AM, Erik de Castro Lopo wrote:
> Hi all,
> 
> I'm currently working on implementing a missing part of a linux-user
> syscall. This syscall includes a function pointer for a callback.
> 
> If one has a 64 bit user space emulation running on a 32 bit host,
> how does one handle the fact that the pointer might be 64 bits?
> 
> Does the fact that the 32 bit host can only ever give out 32 bit
> addreses to the 64 bit guest just cancel out the possibility of
> any problems?

Not that I know anything about QEMU internals yet, but just for fun here's my
armchair philosophizing. My interpretation of the scenario you describe is
that some function exists in a 64-bit instruction set architecture. QEMU/TCG
has translated it to the host's native 32-bit ISA for actual execution. It
seems like you should be exclusively communicating the address of the 32-bit
translated version to the host kernel. I don't think the host kernel could do
anything useful with a pointer to the foreign ISA version, even if it got the
address right.

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Re: [Qemu-devel] Question on pointers in the qemu user space emulation

[Peter Maydell]

On 17 January 2014 06:33, Erik de Castro Lopo <mle+tools@mega-nerd.com> wrote:
> I'm currently working on implementing a missing part of a linux-user
> syscall. This syscall includes a function pointer for a callback.

Which syscall? Callbacks from the kernel are pretty tricky.
Basically you need to register a host function as the callback
with the host kernel, and stash the guest function pointer somewhere
so that when the callback comes in from the host kernel you can
arrange to interrupt the guest and restart it at the desired
location.

Pretty much the only situation we support this for is the special
case of signal handlers. In fact I wasn't even aware there was
any other kind of kernel-to-userspace callback...

thanks
-- PMM

Re: [Qemu-devel] Question on pointers in the qemu user space emulation

[Erik de Castro Lopo]

Peter Maydell wrote:

> On 17 January 2014 06:33, Erik de Castro Lopo <mle+tools@mega-nerd.com> wrote:
> > I'm currently working on implementing a missing part of a linux-user
> > syscall. This syscall includes a function pointer for a callback.
> 
> Which syscall? Callbacks from the kernel are pretty tricky.
> Basically you need to register a host function as the callback
> with the host kernel, and stash the guest function pointer somewhere
> so that when the callback comes in from the host kernel you can
> arrange to interrupt the guest and restart it at the desired
> location.
> 
> Pretty much the only situation we support this for is the special
> case of signal handlers. In fact I wasn't even aware there was
> any other kind of kernel-to-userspace callback...

The syscall is kind of signal related.

When I implemented the POSIX timer syscalls a little while ago I got
them working for my specific use case. Since then someone pointed
out that the implementation was not complete and I'd like to fix
that. The ticket is here:

    https://bugs.launchpad.net/qemu/+bug/1042388#27

and the guest user space test case here:

    https://bugs.launchpad.net/qemu/+bug/1042388/+attachment/3948443/+files/timer_test.c

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: [Qemu-devel] Question on pointers in the qemu user space emulation

[Peter Maydell]

On 17 January 2014 19:20, Erik de Castro Lopo <mle+tools@mega-nerd.com> wrote:
> When I implemented the POSIX timer syscalls a little while ago I got
> them working for my specific use case. Since then someone pointed
> out that the implementation was not complete and I'd like to fix
> that. The ticket is here:
>
>     https://bugs.launchpad.net/qemu/+bug/1042388#27
>
> and the guest user space test case here:
>
>     https://bugs.launchpad.net/qemu/+bug/1042388/+attachment/3948443/+files/timer_test.c

OK, so the test case is using a sigevent with type SIGEV_THREAD,
which means "Notify the process by invoking sigev_notify_function
 "as if" it were the start function of a new thread." However, this
is not what you need to implement, because that is the libc API,
not the syscall API. The syscall actually being done here is:

timer_create(CLOCK_REALTIME, {0x8331098, 32, SIGEV_THREAD_ID, {8113}},
{0x1}) = 0

(libc creates a thread for purposes of making the function calls,
and then asks the kernel to signal that thread so it knows when
to do the calls).

So all you need to do is implement SIGEV_THREAD_ID
correctly, which should be pretty straightforward (you can let
the host kernel deal with the error checking on the thread
ID, you just need to pass all the information through, I think).

thanks
-- PMM