From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37181 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObYBo-0006vQ-HA for qemu-devel@nongnu.org; Wed, 21 Jul 2010 08:14:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObYBd-0000JF-Rm for qemu-devel@nongnu.org; Wed, 21 Jul 2010 08:14:20 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:52380) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObYBd-0000Iy-My for qemu-devel@nongnu.org; Wed, 21 Jul 2010 08:14:09 -0400 Received: by fxm5 with SMTP id 5so3780518fxm.4 for ; Wed, 21 Jul 2010 05:14:08 -0700 (PDT) Message-ID: <4C46E48D.9080303@gmail.com> Date: Wed, 21 Jul 2010 15:14:05 +0300 From: Janne Huttunen MIME-Version: 1.0 Subject: Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO References: <4C46D733.1000208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: andrzej zaborowski Cc: qemu-devel@nongnu.org > No, I think that can't happen, but it would be interesting to bisect > what the guest is doing exactly when this happens. The guest should > not move the "next command" pointer before if has written the command > entirely, this should be enough to guard against executing a partial > command. Unless there's another timing issue somewhere obviously. Well, the guest driver is essentially the one in X.Org git tree here: http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/tree/src Looking at e.g. vmwareSendSVGACmdUpdate and vmwareWriteWordToFIFO in vmware.c, the command seems to be inserted into the FIFO one value at a time. Now, is the whole sequence somehow atomic wrt the host FIFO access or not? > Hmm, I don't know about the guest.. would be good to check too, but it > should be only fixable in the guest if it is so. Is the FIFO protocol documented somewhere? Like what kind of atomicity is expected? > I'm not sure if it's likely that the FIFO is really getting full? > Most guest software will not write too many commands without knowing > that the previous content has appeared on the screen, right? Yes, I agree. That's more of a theoretical issue. > The FIFO can run at any moment but everything else stops until all the > commands currently in the FIFO have been executed. vmware_fifo_run is > called by the UI update which in turn is called from the main select() > loop. Guest code is also executed in that loop. "At any time" as in between guest calls to vmwareWriteWordToFIFO? Or not? It seems to me that the GUI is updated from a timer, but can it go off at any time?