qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH] hw/arm/digic: Mark device with user_creatable = false
Date: Tue, 22 Aug 2017 16:18:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 22.08.2017 16:07, Peter Maydell wrote:
> 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]