Re: 5.0.0-rc3 : Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries

[Peter Maydell]

On Fri, 17 Apr 2020 at 01:43, Dennis Clarke via <address@hidden> wrote:
>
>
> Very strange messages from qemu 5.0.0-rc3 wherein I try to run :

Thanks for the report. Did this work with older QEMU?

> $ /usr/local/bin/qemu-system-ppc64 --version
> QEMU emulator version 4.2.93
> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
> $
> $
> $ /usr/local/bin/qemu-system-ppc64 \
>  > -machine pseries-4.1 -cpu power9 -smp 4 -m 12G -accel tcg \
>  > -drive file=/home/ppc64/ppc64le.qcow2 \
>  > -device virtio-net-pci,netdev=usernet \
>  > -netdev user,id=usernet,hostfwd=tcp::10000-:22 \
>  > -serial stdio -display none -vga none
> qemu-system-ppc64: warning: TCG doesn't support requested feature,
> cap-cfpc=workaround
> qemu-system-ppc64: warning: TCG doesn't support requested feature,
> cap-sbbc=workaround
> qemu-system-ppc64: warning: TCG doesn't support requested feature,
> cap-ibs=workaround
>
>
> SLOF **********************************************************************

[kernel boot log snipped]


> root@titan:~#
>
>  From this point onwards I see an endless stream of :
>
> Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries

> No idea what that is .. but it doesn't look friendly.
>
> Also I did compile qemu with --enable-debug --disable-strip and the
> performance is truely horrific.  I can only assume that those options
> are the cause. Any thoughts from anyone would be wonderful.

Well, you turned on debug and you got some warnings
which are only emitted with debug on, so you can
work around it by not doing that :-) And yes, debug
is slower (it builds QEMU without optimization enabled
so it's easier to debug QEMU in gdb, and it turns on
various extra sanity checks.)

The warning is something we should fix -- it's a bug
in the PPC code generation where we didn't correctly
free a TCG temporary. The good news is that this won't
generally have any visible bad effects, because the
TCG common code will clean all those temporaries up
at the end of each block anyway. The only time the leak
is an issue is if guest code has a straight line sequence
of hundreds of the same instruction in a row, in which
case they'll all be in the same block and we might
hit the limit on total temporaries. That won't happen
unless guest code is deliberately doing something crazy.

David -- is this a known bug?

thanks
-- PMM