From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Li6Cb-0007Vi-Jk for qemu-devel@nongnu.org; Fri, 13 Mar 2009 08:09:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Li6CV-0007SD-90 for qemu-devel@nongnu.org; Fri, 13 Mar 2009 08:09:24 -0400 Received: from [199.232.76.173] (port=60045 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Li6CU-0007S4-Lu for qemu-devel@nongnu.org; Fri, 13 Mar 2009 08:09:18 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:9675) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Li6CU-0000qc-4X for qemu-devel@nongnu.org; Fri, 13 Mar 2009 08:09:18 -0400 Message-ID: <49BA4B9B.7040208@eu.citrix.com> Date: Fri, 13 Mar 2009 12:03:39 +0000 From: Stefano Stabellini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] vnc: shared buffer: skip some optimizations. References: <49B7CE21.4030104@redhat.com> <49B7DC25.6010500@codemonkey.ws> <49B9697C.5020607@redhat.com> In-Reply-To: <49B9697C.5020607@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" Gerd Hoffmann wrote: > Sending screen updates to the client will be done using the server > surface + dirty map only, so the guest updating the screen in parallel > can't cause trouble here. Could you please explain an example of trouble caused by sich situations? Given A, B and C three different points in time with A < B < C, currently what we are doing is: A) getting the guest dirty map B) filtering the guest dirty map using memcmp with the server surface (called old_data in the current code), however the dirty map could be inconsistent with the framebuffer because was set in A C) sending updates to the client from the guest surface based on the dirty map, however the dirty map is inconsistent because it was set in A and filtered in B In any case we get the new dirty map next iteration and it will include all the possible changes that happened after A, possibly already sent to the client inadvertently in C. --- with your patch we have: A) getting the guest dirty map B) setting the server dirty map using the guest dirty map and memcmp with the server surface, however the dirty map could be inconsistent with the guest framebuffer because was set in A C) sending updates to the client from the server surface In any case we get the new dirty map next iteration and it will include all the possible changes that happened after A, possibly already sent to the client inadvertently in C. --- If your goal is to remove possible update incosistencies, your patch certainly removes the one in C, but not the one in B. If your goal is to send the most updated version of the framebuffer to the guest ASAP, the current code is better at it.