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

[Alexander Graf]

> Am 28.02.2014 um 22:21 schrieb Peter Maydell <address@hidden>:
> 
>> 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.)

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