Re: [PATCH 3/3] monitor: only run coroutine commands in qemu_aio_context

[Michael Tokarev]

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.

Thanks,

/mjt