On Tue, 20 Aug 2024 at 12:30, Florian Lugou <florian.lu...@provenrun.com> wrote: > > > > $ aarch64-none-elf-gcc -ffreestanding -nostdlib -T > > > qemu/tests/tcg/aarch64/system/kernel.ld -o test test.S > > > > > > $ qemu-system-aarch64 \ > > > -machine virt,secure=on,gic-version=3 \ > > > -cpu cortex-a57 \ > > > -kernel test \ > > > -display none \ > > > -semihosting > > > > > > $ # Exits after ~1s > > > > > > $ qemu-system-aarch64 \ > > > -machine virt,secure=on,gic-version=3 \ > > > -cpu cortex-a57 \ > > > -kernel test \ > > > -display none \ > > > -semihosting \ > > > -icount shift=0,sleep=off > > > > > > ... (hangs until QEMU is killed) > > > > For me, with QEMU commit 9eb51530c12ae645b, this test case > > exits (doesn't hang) with both these command lines. Do you > > still see this bug? I guess it's possible we fixed it in > > the last month or so, though I can't see anything obviously > > relevant in the git logs. > > Thank you for taking the time to test it. > > On my machine (Ubuntu 22.04), with QEMU configuration options > "--target-list=aarch64-softmmu --enable-debug", running the provided test case > with "-icount shift=0,sleep=off" still makes QEMU hang forever on commit > 9eb51530c12ae645b. > > The issue was initially reported by a colleague of mine so I was hoping it > would > be somehow reliably reproducible. But apparently it is not.
Somebody else reported a similar issue to this to me this week, which reminded me of a different bug that we'd found and fixed in the interim, which was enough of a hint that I figured out why this wasn't reproducible for me. This bug only reproduces if your QEMU binary isn't compiled with slirp support (which will happen if your host system doesn't have libslirp-dev or libslirp-devel installed). If slirp is present then the usermode networking backend will be present and it always has an active timer. Without slirp, the problem manifests when there are no active timers. You can also repro it on a with-slirp compile by adding "-net none" to the command line. I'll have a look at what the underlying bug is... thanks again for the handy test case. thanks -- PMM
