Re: [Qemu-devel] [PATCH] hw/arm/digic: Mark device with user_creatable = false

[Thomas Huth <thuth@redhat.com>]

On 22.08.2017 15:52, Peter Maydell wrote:
> On 22 August 2017 at 14:15, Thomas Huth <thuth@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 <thuth@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.

 Thomas