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

["Alex Bennée" <alex.bennee@linaro.org>]

Michael Matz <matz@suse.de> writes:

> Hi,
>
> On Tue, 25 Feb 2014, Peter Maydell wrote:
>
>> On 25 February 2014 13:33, Michael Matz <matz@suse.de> wrote
>> > The biggest road-block is that signal vs syscall handling is
>> > fundamentally broken in linux-user and it's unfixable without
>> > assembler implementations of the syscall caller.
>> 
>> I'm not entirely sure it's possible to fix even with
>> hand-rolled assembly, to be honest.
>
> I am fairly sure.  The problem is "simply" to detect if the signal arrived 
> while inside the kernel (doing the syscalls job) or still or already 
> outside. This structure helps with that:
<snip>

Is this "simply" a case of having a precise state in/around syscalls?

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. So this case be:

* the execution/translation loop
* a helper function
* a syscall (helper jump out of execution/translation loop?)

I wonder if it would be possible to defer the handing of the signal back
to the process until we know we are precise?

-- 
Alex Bennée
Finding this all eerily familiar.