Re: [libvirt] [PATCH 4/7] libvirt: support an "embed" URI path selector for opening drivers

On Tue, Dec 17, 2019 at 12:41:27PM -0500, Cole Robinson wrote: > The second issue: testing with virt-manager, everything locks up with > OpenGraphicsFD: > > #0 0x00007ffff7a7f07a in pthread_cond_timedwait@(a)GLIBC_2.3.2 () at > /lib64/libpthread.so.0 > #1 0x00007fffe94be113 in virCondWaitUntil (c=c@entry=0x7fffc8071f98, > m=m@entry=0x7fffc8071ed0, whenms=whenms@entry=1576602286073) at > /home/crobinso/src/libvirt/src/util/virthread.c:159 > #2 0x00007fffe44fc549 in qemuDomainObjBeginJobInternal > (driver=driver@entry=0x7fffc8004f30, obj=0x7fffc8071ec0, > job=job@entry=QEMU_JOB_MODIFY, > agentJob=agentJob@entry=QEMU_AGENT_JOB_NONE, > asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, nowait=nowait@entry=false) > at /home/crobinso/src/libvirt/src/qemu/qemu_domain.c:9357 > #3 0x00007fffe4500aa1 in qemuDomainObjBeginJob > (driver=driver@entry=0x7fffc8004f30, obj=<optimized out>, > job=job@entry=QEMU_JOB_MODIFY) at > /home/crobinso/src/libvirt/src/qemu/qemu_domain.c:9521 > #4 0x00007fffe4582572 in qemuDomainOpenGraphicsFD (dom=<optimized out>, > idx=<optimized out>, flags=0) at > /home/crobinso/src/libvirt/src/qemu/qemu_driver.c:18990 > #5 0x00007fffe968699c in virDomainOpenGraphicsFD (dom=0x7fffd0005830, > idx=0, flags=0) at /home/crobinso/src/libvirt/src/libvirt-domain.c:10664 > #6 0x00007fffe98cc6b1 in libvirt_virDomainOpenGraphicsFD () at > /usr/lib64/python3.7/site-packages/libvirtmod.cpython-37m-x86_64-linux-gnu.so > > > I didn't dig into it any more than that. Otherwise in some mild testing > I'm surprised how much things seemed to 'just work' :) Hard to tell but my guess is that there's probably some event loop interaction causing us problems. Obviously this stack trace is waiting for the job lock. I'm guessing that the job lock is held by another API call made from the event loop thread. Will investigate it some more. In libvirtd no libvirt APIs calls are ever made from the event loop thread, they can only be made from worker threads. We'll need to make it clear that apps using the embedded driver must likewise ensure that libvirt APIs calls are *NEVER* made from the event loop thread. This is good practice even when using traditional libvirt connections, because the RPC calls to libvirtd can take an arbitrary amount of time to complete & so make the event loop response very poor.