On Thu, Jun 16, 2011 at 09:21:13PM +0200, Alon Levy wrote: > Hi, > > I just had a short conversation with Marc-Andre about a bug in spice/qxl and > it turns out there are a couple of possible solutions and I require some more > input. >
Forgot: this is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=700134 > The problem: spice was stalling in flush_display_commands caused by > QXL_UPDATE_AREA. Since the vcpu thread is holding the global qemu mutex then > qemu is unresponsive during this time to any other clients, specifically a > libvirt call via virt-manager (virDomainGetXMLDesc) was blocked. > > There are a number of wrong things here, I'll start from what I think we > should fix but any of these would solve this specific problem: > 1. QXL_IO_UPDATE_AREA is synchronous. If we made it async, by using an > interrupt to notify of it's completion, then the io would complete practicaly > immediately, and the mutex would be relinquished. > 2. flush_display_commands is waiting for the client if the PIPE is too > large. This is wrong - why should a slow client prevent the guest from doing > an update area? Presumably we do this to keep the pipe length limited, which > presumably limits the amount of memory. I don't have any numbers, but this > looks wrong to me. > 3. we don't drop qemu's global mutex when dispatching a message. Since an IO > can happen from any vcpu we would need to add our own dispatcher mutex in > spice. > > Any comments are appreciated, > > Alon > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
