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;
 }
 
 static const TypeInfo digic_type_info = {
-- 
1.8.3.1

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? I think we should identify why we don't expect
it to work and state that, rather than just the empirical "didn't
work for me".

Not that it really makes sense to have command line creation
of SoC objects at all really.

thanks
-- PMM

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

On 22 August 2017 at 15:05, Thomas Huth <thuth@redhat.com> wrote:
> 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.

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

On 22.08.2017 16:07, Peter Maydell wrote:
> On 22 August 2017 at 15:05, Thomas Huth <thuth@redhat.com> wrote:
>> 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.
> 
> 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