Am 28.02.2014 um 22:21 schrieb Peter Maydell peter.maydell@linaro.org:
On 28 February 2014 14:12, Alex Bennée alex.bennee@linaro.org wrote: Is this "simply" a case of having a precise state in/around syscalls?
No.
AIUI we already have such a mechanism for dealing with faults in translated code so this is all aimed at when an asynchronous signal arrives somewhere in QEMU's own code.
The major problem is that system calls are supposed to be atomic wrt signals, ie for the guest we must appear to either take the signal first, or have the syscall return EINTR, or take it after. Further, we mustn't make a host syscall that is supposed to be interrupted by a signal if the signal has already arrived, because we'll hang.
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html has a fuller description of the problem, though note that my analysis of the solution is incorrect. I think Michael's right that we could deal with this if we had known native asm for the syscall sequence. (We probably want to separate out the interruptible syscalls so we can continue to use straightforward "just call libc" code for the bulk of them which are non-interruptible.)
Could we check the instruction at the sognaling pc and check if it's a known syscall instruction? No need to replace glibc wrappers then.
Alex
thanks -- PMM