Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

[Peter Maydell]

On 28 February 2014 14:12, Alex Bennée <address@hidden> 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