On 22.08.2017 16:07, Peter Maydell wrote: > On 22 August 2017 at 15:05, Thomas Huth <th...@redhat.com> wrote: >> On 22.08.2017 15:52, Peter Maydell wrote: >>> On 22 August 2017 at 14:15, Thomas Huth <th...@redhat.com> wrote: >>>> QEMU currently hangs completely when the user is trying to do a >>>> "device_add digic" on an unrelated ARM machine like integratorcp. >>>> Looks like this device is not meant to be hot-pluggable at all, so >>>> let's simply mark it with "user_creatable = false" to avoid the hang. >>>> >>>> Signed-off-by: Thomas Huth <th...@redhat.com> >>>> --- >>>> hw/arm/digic.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/hw/arm/digic.c b/hw/arm/digic.c >>>> index 94f3263..208dfb3 100644 >>>> --- a/hw/arm/digic.c >>>> +++ b/hw/arm/digic.c >>>> @@ -101,6 +101,8 @@ static void digic_class_init(ObjectClass *oc, void >>>> *data) >>>> DeviceClass *dc = DEVICE_CLASS(oc); >>>> >>>> dc->realize = digic_realize; >>>> + /* Reason: Hangs QEMU when trying to device_add this directly */ >>>> + dc->user_creatable = false; >>>> } >>> >>> Maybe "uses serial_hds[]" is a better reason, or does it hang for >>> some other reason? >> >> When I kill the hanging QEMU, the stack trace looks like this: >> >> #0 0x00007ffff13afaff in ppoll () at /lib64/libc.so.6 >> #1 0x0000555555bb3179 in qemu_poll_ns (__ss=0x0, __timeout=0x7fffffffda60, >> __nfds=<optimized out>, __fds=<optimized out>) >> at /usr/include/bits/poll2.h:77 >> #2 0x0000555555bb3179 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized >> out>, timeout=timeout@entry=1000000000) >> at /home/thuth/devel/qemu/util/qemu-timer.c:334 >> #3 0x0000555555bb3f88 in main_loop_wait (timeout=1000000000) at >> /home/thuth/devel/qemu/util/main-loop.c:255 >> #4 0x0000555555bb3f88 in main_loop_wait (nonblocking=nonblocking@entry=0) >> at /home/thuth/devel/qemu/util/main-loop.c:515 >> #5 0x000055555578d927 in main () at /home/thuth/devel/qemu/vl.c:1917 >> #6 0x000055555578d927 in main (argc=<optimized out>, argv=<optimized out>, >> envp=<optimized out>) at /home/thuth/devel/qemu/vl.c:4791 >> >> I haven't investigated any further, but the usage of serial_hds >> in the realize function could certainly be the reason. At least >> it certainly is a reason that this device should not be creatable >> by the user - so let me send a v2 with the comment changed >> accordingly. > > Has QEMU itself actually hung (no response to monitor etc), or is > that just the guest sitting doing nothing? "QEMU is sat in the main > loop waiting for something to happen" is what you'd expect in the > latter case. The backtraces for the other threads might be of > interest or might also be unhelpful.
I thought that QEMU would hang ... but now I checked again, and it's just that it does not return to the monitor prompt as expected. If I press CTRL-a c again, I can get to the monitor again. Anyway, QEMU then dies if I try to remove the device with device_del: qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) ... so let's simply mark it with user_creatable = false and call it a day... ;-) Thomas
