Upon trying to get m68k working, I found to my horror that every workload that used perl or python would panic, with: > TODO /tmp/build/tmp-qemu/qemu-5.0.0/tcg/tci.c:597: tcg_qemu_tb_exec() > /tmp/build/tmp-qemu/qemu-5.0.0/tcg/tci.c:597: tcg fatal error (Not exact copy, just the copy from the article[1] I found that lead me to the solution when I saw the same issue from the same function) A contributor to qemu also recently said: <> kent\n: but yeah - it will be m68k doing some vector-like FP loads which TCI hasn't implemented (because it is essentially unmaintained) And in practice, even when it didn't fail, the performance was abysmal, in a "when eselect doesn't panic trying to invoke python, eselect takes 2-seconds per line of output when using binfmt_misc + qemu-m68k" sort of way. At a minimum, I'd hope that known modes where its a bit spicy, such as: tci + m68k Give a hearty warning, or better, if warranted, blocks the combination (because it really doesn't work at all), or better, the USE flag is nuked entirely. Especially given the USE description *kinda* misleads you into thinking it has a chance of improving things, when the opposite is much more likely ( already getting semi-native performance with qemu-m68k ) > app-emulation/qemu[tci] Enable the TCG Interpreter which can speed up or slowdown workloads depending on the host and guest CPUs being emulated. In the future it will be a runtime option but for now its compile time. The nature of it being both volatile *and* unmaintained are really not encapsulated in that USE description :) 1: https://www.linuxquestions.org/questions/slackware-14/qemu-5-0-0-alien-build-crashes-trying-to-boot-raspbian-buster-as-a-rpi3-4175680027/
It should also be at the *very* *least* package.use.stable.mask'd , because that feature cannot be considered stable.
tci is not specific to m68k. m68k in general is a bit shaky in qemu.
(In reply to Sergei Trofimovich from comment #2) > tci is not specific to m68k. m68k in general is a bit shaky in qemu. I can confirm extreme slowness/unstableness on amd64 host aarch64 target user emulation with TCI enabled.
(In reply to Sergei Trofimovich from comment #2) > tci is not specific to m68k. m68k in general is a bit shaky in qemu. Maybe, but without TCI I can actually build/upgrade stuff without apparent issues. But with it, its a complete showstopper. "Cant run python or perl" is a hard "no gentoo"
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8bf80111ae3a9c73b916ce195731ed65090ac694 commit 8bf80111ae3a9c73b916ce195731ed65090ac694 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-10-06 08:25:50 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-10-06 08:26:36 +0000 app-emulation/qemu: drop USE=tci TCG interpreter (TCI) has a few limitations: - it does not support FPU - it's generally slower on non-self-modifying code It's advantage is support for host architectures where native codegeneration is not implemented. Gentoo has qemu keyworded only on targets with native code generation available. Avoid the interpreter. Reported-by: Kent Fredric Closes: https://bugs.gentoo.org/746752 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> app-emulation/qemu/metadata.xml | 1 - app-emulation/qemu/qemu-5.1.0-r1.ebuild | 13 +++++++++++-- app-emulation/qemu/qemu-5.1.0.ebuild | 13 +++++++++++-- app-emulation/qemu/qemu-9999.ebuild | 13 +++++++++++-- 4 files changed, 33 insertions(+), 7 deletions(-)
