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

[Michael Matz]

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:

before:
    setup args and stuff for syscall to do
atsys:
    syscall insn (single insn!)
after:
    mov return, return-register-per-psABI
realafter:
    rest of stuff

When a signal arrives you look at the return address the kernel puts into 
the siginfo.  Several cases:

* before <= retaddr < atsys:
  syscall hasn't yet started, so break syscall sequence, handle signal in 
  main loop, redo the syscall.
* atsys == retaddr
  syscall has started and the kernel wants to restart it after sighandler
  returns, _or_ syscall was just about to be started.  No matter what,
  the right thing to do is to actually do the syscall (again) after 
  handling the signal.  So break syscall sequence, handle signal in main
  loop, (re)do the syscall.
* after <= retaddr < realafter:
  syscall is complete but return value not yet in some variable but still 
  in register (or other post-syscall work that still needs doing isn't
  complete yet); nothing interesting to do, just let it continue with the 
  syscall sequence, handle signal in main loop after that one returned.
* retaddr any other value:
  uninteresting; actually I'm not sure we'd need the distinction between 
  after and realafter.  Handle signal as usual in main loop.

The important thing for qemu is to know precisely if the signal arrived 
before the syscall was started (or is to be restarted), or after it 
returned, and for that the compiler must not be allowed to insert any code 
between atsys and after.

> However there are a bunch of bugfixes in your tree
> which it would be really nice to see upstreamed:
> the sendmmsg patch, for instance. We can at least
> get the aarch64 support to the same level as the
> 32 bit arm linux-user setup, which is genuinely
> useful to people despite the well known races and
> locking issues.

Yeah.


Ciao,
Michael.