Re: qemu-user (arm64) fails (null ptr deref) under qemu-system-x86_64 w/o avx?

[Michael Tokarev]

Hello Richard!

22.05.2022 04:17, Richard Henderson wrote:
> On 5/18/22 02:13, Michael Tokarev wrote:
> > Hi!
> >
> > Here's an interesting bug. Interesting because qemu-user does not run under 
> > qemu-system.
> >
> > Running 7.0.0 qemu-aarch64-static under 7.0.0 qemu-system-x86_64 -enable-kvm 
> > with
> > default cpu type, getting:
>
> What is the test case?
>
> I thought I'd be able to see the same problem by disabling AVX support in 
> tcg/i386/tcg-target.c.inc.  But so far everything I have tried works.

Do you really mean "everything", that is, you didn't able to reproduce it at 
all?

> And for completeness, what's the compiler that produced the qemu-aarch64-static 
> binary?

And this is a *very* good question really. Even better than I initially thought.

Because I think it all started after gcc upgrade on debian and recompiling
qemu-user with the new compiler. There was no other user-related changes in
the version of qemu-user binary in debian which triggered this issue in the
first place.  Becaise the reporter found which particular package upgrade
causes this new issue to appear. It is the upgrade of qemu-user-static
package in debian, minor version upgrade from 7.0.0-2 to 7.0.0-3 with
changes in the packaging which are unrelated to qemu-user (actually to
any code, - just the packaging stuff).

Now I'm even more puzzled than before.  Because both packages were compiled
by the same tool set versions. In particular, it was gcc-12 (= 12-20220428-1).
I *thought* it is a gcc upgrade which caused that, but it is not. Compiler
flags used, other relevant packages - it's all the same (we did upgrade, say,
libsdl, but it is obviously has no effect on qemu-user).

(Here's the initial bug report about this: https://bugs.debian.org/1011003 -
but it contains too much unrelated information).

I can reproduce the problem locally quite easily. I can't reproduce it on
a baremetal system without AVX support (tried on a few older systems, in
particular on a Celeron N3050) - it works there just fine, the same binary
which fails under qemu-system. Previous qemu-aarch64-static works fine,
this qemu-aarch64-static breaks, this qemu-aarch64-static but built on
an older debian system (bullseye, with older toolchain) works fine either
way.

Even under qemu-system it has somewhat strange (but 100% reproducible, with
exactly the same null-ptr deref) results: eg. it still fails with
qemu-system-x86_64 -cpu Westmere,+avx, - so turning on avx for westmere does
not fix it. But removing avx from SandyBridge does trigger it.  So it is not
*just* avx, it is something more interesting than that. Maybe it is the
qemu-system which does something wrong, not the qemu-user - because we can't
reproduce it on a few baremetal systems (but it is way more difficult to
experiment in this context obviously, since you can't turn CPU features on/off
at will there).

Hmm...... :)

/mjt