On 28 February 2014 14:12, Alex Bennée <alex.ben...@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.) thanks -- PMM
