On Fri, 17 Apr 2020 at 01:43, Dennis Clarke via <qemu-discuss@nongnu.org> 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