[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