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.

 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

Reply via email to