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

[Peter Maydell]

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

thanks
-- PMM