On Tue, 2025-04-01 at 13:58 +0200, Philippe Mathieu-Daudé wrote:
> On 1/4/25 13:43, David Woodhouse wrote:
> > On Tue, 2025-04-01 at 13:30 +0200, Philippe Mathieu-Daudé wrote:
> > > On 1/4/25 13:18, Philippe Mathieu-Daudé wrote:
> > > > Hi David,
> > > >
> > > > On 8/1/25 14:51, David Woodhouse wrote:
> > > > > On Tue, 2024-12-31 at 21:22 +0100, Philippe Mathieu-Daudé
> > > > > wrote:
> > > > > >
> > > > > > This change tidies up main thread management to be more
> > > > > > flexible.
> > > > > >
> > > > > > * The qemu_main global function pointer is a custom
> > > > > > function
> > > > > > for the
> > > > > > main thread, and it may now be NULL. When it is, the
> > > > > > main
> > > > > > thread
> > > > > > runs the main Qemu loop. This represents the
> > > > > > traditional
> > > > > > setup.
> > > > > > * When non-null, spawning the main Qemu event loop on a
> > > > > > separate
> > > > > > thread is now done centrally rather than inside the
> > > > > > Cocoa
> > > > > > UI code.
> > > > > > * For most platforms, qemu_main is indeed NULL by
> > > > > > default,
> > > > > > but on
> > > > > > Darwin, it defaults to a function that runs the
> > > > > > CFRunLoop.
> > > > > > * The Cocoa UI sets qemu_main to a function which runs
> > > > > > the
> > > > > > NSApplication event handling runloop, as is usual for
> > > > > > a
> > > > > > Cocoa app.
> > > > > > * The SDL UI overrides the qemu_main function to NULL,
> > > > > > thus
> > > > > > specifying that Qemu's main loop must run on the main
> > > > > > thread.
> > > > > > * The GTK UI also overrides the qemu_main function to
> > > > > > NULL.
> > > > > > * For other UIs, or in the absence of UIs, the
> > > > > > platform's
> > > > > > default
> > > > > > behaviour is followed.
> > > > >
> > > > > When exiting an emulated Xen guest with <Ctrl-a x> on the
> > > > > console, I
> > > > > now see:
> > > > >
> > > > > (gdb) run
> > > > > Starting program: /home/dwmw2/git/qemu/ball/qemu-system-
> > > > > x86_64 -
> > > > > display none -vga none -serial mon:stdio -machine q35 -accel
> > > > > kvm,xen-
> > > > > version=0x4000a,kernel-irqchip=split -smp 2 -kernel
> > > > > /home/dwmw2/
> > > > > avocado/data/cache/by_name/bzImage -append printk.time=0\
> > > > > root=/dev/
> > > > > xvda\ console=ttyS0\ xen_emul_unplug=ide-disks\
> > > > > xen_no_vector_callback\ noapic\ loglevel=0 -drive
> > > > > file=/home/dwmw2/
> > > > > avocado/data/cache/by_name/
> > > > > rootfs.ext4,if=none,snapshot=on,format=raw,id=drv0 -device
> > > > > xen-
> > > > > disk,drive=drv0,vdev=xvda -device virtio-net-pci,netdev=unet
> > > > > -
> > > > > netdev
> > > > > user,id=unet,hostfwd=:127.0.0.1:0-:22
> > > > >
> > > > > Starting syslogd: OK
> > > > > Starting klogd: OK
> > > > > Running sysctl: OK
> > > > > Saving 256 bits of non-creditable seed for next boot
> > > > > Starting network: OK
> > > > > Starting dhcpcd...
> > > > > no such user dhcpcd
> > > > > dhcpcd-9.4.1 starting
> > > > > no interfaces have a carrier
> > > > > forked to background, child pid 111
> > > > > Starting dropbear sshd: OK
> > > > > #
> > > > > QEMU: Terminated
> > > > > qemu-system-x86_64: ../block/block-backend.c:1290:
> > > > > blk_in_drain:
> > > > > Assertion `qemu_in_main_thread()' failed.
> > > > >
> > > > > Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted.
> > > > > 0x00007ffff5ffc724 in __pthread_kill_implementation () from
> > > > > /lib64/
> > > > > libc.so.6
> > > > > (gdb) bt
> > > > > #0 0x00007ffff5ffc724 in __pthread_kill_implementation () at
> > > > > /lib64/
> > > > > libc.so.6
> > > > > #1 0x00007ffff5fa3d1e in raise () at /lib64/libc.so.6
> > > > > #2 0x00007ffff5f8b942 in abort () at /lib64/libc.so.6
> > > > > #3 0x00007ffff5f8b85e in __assert_fail_base.cold () at
> > > > > /lib64/libc.so.6
> > > > > #4 0x00007ffff5f9be47 in __assert_fail () at
> > > > > /lib64/libc.so.6
> > > > > #5 0x0000555555abf911 in blk_in_drain (blk=0x555557ca6680)
> > > > > at ../block/block-backend.c:1290
> > > > > #6 0x000055555593410c in xen_block_dataplane_stop
> > > > > (dataplane=0x555558982950)
> > > > > at ../hw/block/dataplane/xen-block.c:695
> > > > > #7 0x000055555593441a in xen_block_dataplane_stop
> > > > > (dataplane=<optimized out>)
> > > > > at ../hw/block/dataplane/xen-block.c:689
> > > > > #8 0x00005555555dfd5e in xen_block_disconnect
> > > > > (xendev=xendev@entry=0x55555880aa60, errp=<optimized
> > > > > out>)
> > > > > at ../hw/block/xen-block.c:172
> > > > > #9 0x00005555555dfeca in xen_block_unrealize
> > > > > (xendev=0x55555880aa60)
> > > > > at ../hw/block/xen-block.c:282
> > > > > #10 0x000055555578ef71 in xen_device_unrealize
> > > > > (dev=<optimized
> > > > > out>)
> > > > > at ../hw/xen/xen-bus.c:978
> > > > > #11 0x0000555555bfe65f in notifier_list_notify
> > > > > (list=<optimized
> > > > > out>,
> > > > > data=0x0)
> > > > > at ../util/notify.c:39
> > > > > #12 0x00007ffff5fa6461 in __run_exit_handlers () at
> > > > > /lib64/libc.so.6
> > > > > #13 0x00007ffff5fa652e in exit () at /lib64/libc.so.6
> > > > > #14 0x0000555555b523dc in qemu_default_main
> > > > > (opaque=opaque@entry=0x0)
> > > > > #15 0x00005555555609c0 in main (argc=<optimized out>,
> > > > > argv=<optimized
> > > > > out>) at ../system/main.c:76
> > > > >
> > > >
> > > > Is this still an issue?
> > >
> > > Likely fixed by commit e7bc0204 ("system/runstate:
> > > Fix regression, clarify BQL status of exit notifiers"), so
> > > I'm closing https://gitlab.com/qemu-project/qemu/-/issues/2771.
> >
> > Indeed. I think I was assuming the explicit Resolves: tag in that
> > commit was going to magically close the issue when it was merged.
> > Should I have closed it manually?
>
> It should have been closed automatically. Maybe some transient
> problem on GitLab side ¯\_(ツ)_/¯Ack. Thanks for confirming.
smime.p7s
Description: S/MIME cryptographic signature
