Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO

[andrzej zaborowski]

Hi,

On 21 July 2010 13:17, Janne Huttunen <address@hidden> wrote:
> Now, correct me if I'm wrong, but isn't vmsvga_fifo_run() called
> from an asynchronous context (wrt the guest)? If that indeed is
> so, it may very well be, that it is run while the guest is
> modifying the FIFO. This means, that a command may found in the
> FIFO, but its arguments may not be there yet.

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.

Can you check whether this also happens without kvm?

>
> AFAICT the code just seems to check that the FIFO is not empty
> before reading the command, but then assumes that the rest of
> the command arguments are also there and reads the FIFO without
> further checks. If it is possible that part of the command is
> missing, this will desynchronize the FIFO. As there seems to be
> no mechanism for re-syncing it, we're toast.
>
> Also, if the FIFO gets full, the guest will force the FIFO to
> be run. Now, AFAICT there is no guarantee on the guest side
> that the last command in the FIFO won't be incomplete when this
> happens. This will desynchronize the FIFO the same way and
> can happen even if all the calls to vmsvga_fifo_run() are
> synchronized.

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.

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?

>
> It seems to me that the FIFO handling probably needs some way to
> "peek" into the FIFO to see if the command in there is complete
> and delay executing it if parts of it are still missing. That
> should work in all cases except if a single command can be so big
> that it won't fit in the FIFO. The other alternative I can think
> of is to implement the vmsvga_fifo_run() as a state machine that
> can read a partial command from the FIFO and continue it on the
> next call.
>
> Finally, if it indeed is true that the FIFO can be run both
> asynchronously and forced by the guest, shouldn't the access to
> the FIFO also be protected between these two somehow? At least I
> couldn't find any such mechanism, but I must admit that I may
> have easily just missed it.

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.

Cheers