Broken SuperH atomics in qemu app-level emulation

Broken SuperH atomics in qemu app-level emulation

[Rich Felker]

While testing the inline sh4a atomics patch for musl (see
http://www.openwall.com/lists/musl/2015/05/17/22) I noticed that
qemu-sh4 crashed on the instructions used for atomics, which are only
available in sh4a. Adding -cpu SH7785 made it work, but that got me
wondering what's happening when we don't build musl with -m4a
(resulting in the new inline atomics) but instead use a more baseline
target like -m4 where the type of atomics to use has to be detected at
runtime.

musl's runtime atomic detection for SuperH is based on the
CPU_HAS_LLSC bit of AT_HWCAP. Under qemu app-level emulation, the
value for AT_HWCAP is always 0, even with -cpu SH7785. This causes
musl to choose the GUSA atomics, rather than the actual atomic
instructions. That's a big problem, because there's no way GUSA can
work with app-level emulation; the whole concept of GUSA relies on the
kernel detecting that it preempted a GUSA atomic sequence and
resetting the program counter the next time the task is scheduled, but
app-level emulation has no kernel and no control over scheduling, and
thus no way to make GUSA work.

At the very least qemu-sh4 should provide a correct value of AT_HWCAP
so we get working atomics with -cpu SH7785. And since the GUSA atomic
model can't work with app-level emulation, I really think qemu-sh4
should either default to -cpu SH7785 or always expose the
synco/mov.li/mov.co opcodes (and hwcap) regardless of the -cpu
setting.

Rich

Re: Broken SuperH atomics in qemu app-level emulation

[Richard Henderson]

On 05/17/2015 08:05 PM, Rich Felker wrote:
> At the very least qemu-sh4 should provide a correct value of AT_HWCAP
> so we get working atomics with -cpu SH7785. And since the GUSA atomic
> model can't work with app-level emulation, I really think qemu-sh4
> should either default to -cpu SH7785 or always expose the
> synco/mov.li/mov.co opcodes (and hwcap) regardless of the -cpu
> setting.

I agree with AT_HWCAP and defaulting to SH7785.  Aurelien?


r~

Re: Broken SuperH atomics in qemu app-level emulation

[Aurelien Jarno]

On 2015-05-20 12:16, Richard Henderson wrote:
> On 05/17/2015 08:05 PM, Rich Felker wrote:
> > At the very least qemu-sh4 should provide a correct value of AT_HWCAP
> > so we get working atomics with -cpu SH7785. And since the GUSA atomic
> > model can't work with app-level emulation, I really think qemu-sh4
> > should either default to -cpu SH7785 or always expose the
> > synco/mov.li/mov.co opcodes (and hwcap) regardless of the -cpu
> > setting.
> 
> I agree with AT_HWCAP and defaulting to SH7785.  Aurelien?

I agree, but for linux-user only. In general we should default to the
most capable CPU when possible. For the softmmu emulation, QEMU doesn't
emulate it fully, but only the instruction set, so we should keep the
current default CPU.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net