On Sat, 3 Feb 2024 at 06:30, Michael Tokarev <m...@tls.msk.ru> wrote: > > 03.02.2024 12:01, Michael Tokarev wrote: > ... > > This change broke something in 7.2. I'm still debugging it, will > > come with a follow-up once some more details are found, I'll also > > check current master with and without this commit. > > > > The prob happens with multiple suspend-resume cycles, - with this > > change applied, guest does not work as expected after *second* > > suspend-resume. > > So, it turned out the prob here exists on master too, and manifests > itself the same way on 7.2.9 or on 8.2.1, - in all cases where we > have this change applied it works (or breaks) equally. > > A (simple) reproducer so far is a hibernate test, - it fails *only* > after suspend-to-ram, but works fine after just hibernate. > > I used just an initrd (with a drive image used for swap - > for hibernation space). > > qemu-img create s.img 256M > mkswap s.img > qemu-system-x86_64 \ > -serial stdio -vga none -display none -parallel none -net none \ > -machine q35 \ > -drive file=s.img,if=ide,format=raw \ > -m 256 \ > -monitor unix:ttyS0,server,nowait \ > -kernel /boot/vmlinuz-6.1.0-15-amd64 \ > -initrd /boot/initrd.img-6.1.0-15-amd64 \ > -append "shell=/bin/sh console=ttyS0 root=none" > > There, in the guest (it has busybox only here): > # swapon /dev/sda > # echo mem > /sys/power/state > (system_wakeup on the monitor) > # echo disk > /sys/power/state > > The system will hibernate but *not* turn off power, qemu > will continue running, while all console messages are the > same as when it works fine. qemu process is spinning up > with 100% cpu usage at this stage. > > Without the intermediate suspend-to-ram or without the > commit in question, qemu process will exit normally at > this stage. > > This is a somewhat patalogical test case, but I see it as an > indicator of something else being wrong, like we aren't saving > or restoring some state now which we should do. > > The tight loop also suggests we're not having success in there.
I'm unable to reproduce this. QEMU v8.2.0, v8.1.0, and even v7.2.0 all spin with 100% CPU usage on my machine. It looks to me like this behavior is not a regression caused by this commit. Do v7.2.0, v8.1.0, and v8.2.0 terminate QEMU on your machine? Stefan
