On Thu, Jul 07, 2011 at 09:29:47AM +0200, Gerd Hoffmann wrote: > >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 could use the cookies, but since I'm already doing a guest_bug when guest does two asyncs overlapping, I think I can just use the last remembered one I store for the express purpose of discovering this bug (until now). > >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 Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
