Re: [Qemu-devel] Question on pointers in the qemu user space emulation
On 17 January 2014 19:20, Erik de Castro Lopo 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
Re: [Qemu-devel] Question on pointers in the qemu user space emulation
Peter Maydell wrote: > On 17 January 2014 06:33, Erik de Castro Lopo 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
On 17 January 2014 06:33, Erik de Castro Lopo 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
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.
[Qemu-devel] Question on pointers in the qemu user space emulation
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/