From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8bR9-0001xK-KS for qemu-devel@nongnu.org; Mon, 03 Sep 2012 14:31:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8bR8-0007YA-Es for qemu-devel@nongnu.org; Mon, 03 Sep 2012 14:31:51 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:56206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8bR8-0007Xp-6P for qemu-devel@nongnu.org; Mon, 03 Sep 2012 14:31:50 -0400 Date: Mon, 3 Sep 2012 14:31:44 -0400 (EDT) From: Alon Levy Message-ID: <211839095.25718934.1346697104418.JavaMail.root@redhat.com> In-Reply-To: <1346694835-23590-3-git-send-email-sandmann@cs.au.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Spice-devel] [PATCH 3/5] Process outstanding commands in the ring after changing capability bits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?S=C3=B8ren?= Sandmann Cc: =?utf-8?Q?S=C3=B8ren?= Sandmann Pedersen , spice-devel@freedesktop.org, qemu-devel@nongnu.org > From: S=C3=B8ren Sandmann Pedersen >=20 > When a new client connects, there may be commands in the ring that it > can't understand, so we need to process these before forwarding new > commands to the client. By doing this after changing the capability > bits we ensure that the new client will never see a command that it > doesn't understand (under the assumption that the guest will read and > obey the capability bits). ACK. We really should have some sort of fence mechanism for this. This patch wil= l still work, since the command ring is 32 items long, so it should be rela= tively cheap to flush it (each item is a single comamnd. worse case can be = 32*video_mem). There is still a race - the guest has to handle the interrup= t before sending any new commands. In the future we could introduce a new command called QXLFence and have the= interrupt handler call a new io to return it just before pushing it to the= ring. The fence would be used only in the server right now, but when the d= river releases it it can use it to know all commands before it have been pr= ocessed (note that it doesn't mean all those commands have been released). > --- > server/red_worker.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) >=20 > diff --git a/server/red_worker.c b/server/red_worker.c > index 60b5471..f87967c 100644 > --- a/server/red_worker.c > +++ b/server/red_worker.c > @@ -9493,6 +9493,11 @@ static void > on_new_display_channel_client(DisplayChannelClient *dcc) > } > red_channel_client_ack_zero_messages_window(&dcc->common.base); > if (worker->surfaces[0].context.canvas) { > + int ring_is_empty; > + > + while (red_process_commands(worker, MAX_PIPE_SIZE, > &ring_is_empty)) { > + } > + > red_current_flush(worker, 0); > push_new_primary_surface(dcc); > red_push_surface_image(dcc, 0); > -- > 1.7.4 >=20 > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel >