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.

Reply via email to