qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Date: Fri, 28 Feb 2014 14:12:27 +0000
User-agent: mu4e 0.9.9.6pre2; emacs 24.3.50.10

Michael Matz <address@hidden> writes:

> Hi,
>
> On Tue, 25 Feb 2014, Peter Maydell wrote:
>
>> On 25 February 2014 13:33, Michael Matz <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]