Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Hi, On Tue, 25 Feb 2014, Andreas Färber wrote: > >> There are some pretty large differences between these trees with > >> respect to signal syscalls - is that the likely culprit? > > > > Quite likely. We explicitly concentrated on the arch64 specific > > instruction emulation leaving more generic patches to flow in from > > SUSE as they matured. > > > > I guess it's time to go through the remaining patches and see what's > > up-streamable. > > > > Alex/Michael, > > > > Are any of these patches in flight now? > > I don't think so, Alex seems to hate cleaning that stuff up... :P > > Compare https://github.com/openSUSE/qemu/commits/opensuse-1.7 for our > general queue. We have patches adding locking to TCG, and there's a hack > pinning the CPU somewhere. The locking and pinning is all wrong (resp. overbroad). The aarch64-1.6 branch contains better implementations for that and some actual fixes for aarch64' userspace. Somehow I don't find the time to go through our patches in linux-user and submit them. 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. That is also still broken on the suse branch where I tried various ways to fix that until coming to that conclusion. Ciao, Michael.___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Hi, On Tue, 25 Feb 2014, Peter Maydell wrote: > On 25 February 2014 13:33, Michael Matz 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. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Hi, On Wed, 26 Feb 2014, Dann Frazier wrote: > I've narrowed down the changes that seem to prevent both types of > segfaults to the following changes that introduce a wrapper around > sigprocmask: > > https://github.com/susematz/qemu/commit/f1542ae9fe10d5a241fc2624ecaef5f0948e3472 > https://github.com/susematz/qemu/commit/4e5e1607758841c760cda4652b0ee7a6bc6eb79d > https://github.com/susematz/qemu/commit/63eb8d3ea58f58d5857153b0c632def1bbd05781 > > I'm not sure if this is a real fix or just papering over my issue - It's fixing the issue, but strictly speaking introduces an QoI problem. SIGSEGV must not be controllable by the guest, it needs to be always deliverable to qemu; that is what's fixed. The QoI problem introduced is that with the implementation as is, the fiddling with SIGSEGV is detectable by the guest. E.g. if it installs a segv handler, blocks segv, then forces a segfault, checks that it didn't arrive, then unblocks segv and checks that it now arrives, such testcase would be able to detect that in fact it couldn't block SIGSEGV. Luckily for us, the effect of blocking SIGSEGV and then generating one in other ways than kill/sigqueue/raise (e.g. by writing to NULL) are undefined, so in practice that QoI issue doesn't matter. To fix also that latter part it'd need a further per-thread flag segv_blocked_p which needs to be checked before actually delivering a guest-directed SIGSEGV (in comparison to a qemu-directed SEGV), and otherwise requeue it. That's made a bit complicated when the SEGV was process-directed (not thread-directed) because in that case it needs to be delivered as long as there's _any_ thread which has it unblocked. So given the above undefinedness for sane uses of SEGVs it didn't seem worth the complication of having an undetectable virtualization of SIGSEGV. > but either way, are these changes reasonable for upstream submission? IIRC the first two commits (from Alex Barcelo) were submitted once in the past, but fell through the cracks. Ciao, Michael. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Hi, On Mon, 10 Mar 2014, Alex Bennée wrote: > > Not sure there's much point looking very deeply into this. Java > > programs are threaded, threaded programs don't work under QEMU => > > don't try to run Java under QEMU :-) > > Having said that I'm sure there was another SIGILL related crash on > Launchpad and I think we would be interested in those. Is JAVA really > that buggy under QEMU just because of threading? Generally speaking, yes. I've never seen problems with openjdk (with the suse tree), so the segfault above might be also be related to the segfault handling for read-only data segments containing code (the signal trampoline on stack), for which the patches were recently proposed upstream. Ciao, Michael.___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
