[Spice-devel] synchronous io considered harmful

Alon Levy alevy at redhat.com
Thu Jun 16 12:21:13 PDT 2011


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


More information about the Spice-devel mailing list