Hi,
I find it problematic to decouple the qxl operations upon QXL_IO and the
worker operations. For example: upon destroy_surfaces, the qxl resets
the tracked guest commands. However, since destroy_surfaces is asynced,
the worker might read commands from the ring before handling destroy
surfaces, and then the qxl guest commands will be modified.

That should be fixed on the qemu side I think. qxl should update its status when it receives the notification that the operation is complete, not after submitting the request.

(Ha! first use case for the magic cookie ;)

I suggest a partial decoupling: on async io, the dispatcher will still
wait for RED_WORKER_MESSAGE_READY, but the server will set it
immediately when it receives the async message.

No. I don't want async messages take a round trip to the worker thread. Even if the worker sends an answer instantly alone the thread scheduling adds noticeable latencies.

cheers,
  Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Reply via email to