Re: [Qemu-devel] [Qemu-block] RFC cdrom in own thread?

[Peter Lieven <pl@kamp.de>]

Am 17.06.2015 um 10:35 schrieb Kevin Wolf:
> Am 16.06.2015 um 17:34 hat Stefan Hajnoczi geschrieben:
>> On Tue, Jun 16, 2015 at 3:44 PM, Peter Lieven <pl@kamp.de> wrote:
>>> I wonder how difficult it would be to have the IDE CDROM run in its own
>>> thread?
>>> We usually have ISOs mounted on an NFS share as CDROM. Problem: If the NFS
>>> Share
>>> goes down, it takes down monitor, qmp, vnc etc. with it.
>>>
>>> Maybe its already possible to do this via cmdline args?
>>>
>>> Any ideas, comments?
>> If QEMU hangs in the read/write/flush/discard code path due to NFS
>> downtime it is a bug.
>>
>> QEMU is expected to hang in open/reopen because those are performed in
>> a blocking fashion.
>>
>> Which of these cases applies to what you are seeing?  Maybe it can be fixed.
> Don't forget bdrv_drain_all(), which is called a lot by the monitor. So
> no matter what you do (and this includes moving to a thread as in a
> hypothetical "ATAPI dataplane"), you end up with a hang sooner or later.

It seems like the mainloop is waiting here:

#0  0x00007ffff606c89c in __lll_lock_wait ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1  0x00007ffff6068065 in _L_lock_858 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2  0x00007ffff6067eba in pthread_mutex_lock ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3  0x00005555559f2557 in qemu_mutex_lock (mutex=0x555555ed6d40)
     at util/qemu-thread-posix.c:76
         err = 0
         __func__ = "qemu_mutex_lock"
#4  0x00005555556306ef in qemu_mutex_lock_iothread ()
     at /usr/src/qemu-2.2.0/cpus.c:1123
No locals.
#5  0x0000555555954a87 in os_host_main_loop_wait (timeout=79413589)
     at main-loop.c:242
         ret = 1
         spin_counter = 0
#6  0x0000555555954b5f in main_loop_wait (nonblocking=0) at main-loop.c:494
         ret = 15
         timeout = 4294967295
         timeout_ns = 79413589
#7  0x000055555575e702 in main_loop () at vl.c:1882
         nonblocking = false
         last_io = 1

Peter