qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Janne Huttunen
Subject: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
Date: Wed, 21 Jul 2010 14:17:07 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5


Hi!

I'm trying to run a Linux guest on top of QEMU (kvm). The only VGA
emulation that seems to give any kind of usable performance is the
vmware SVGA adapter, but that in turn is very unstable. It usually
freezes the guest display within a minute or two and starts printing
an error like "vmsvga_fifo_run: Unknown command 0xffffff in SVGA
command FIFO". A bit of googling tells that I'm not the only one
with this problem (1).

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.

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.

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.


(1): https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/595427





reply via email to

[Prev in Thread] Current Thread [Next in Thread]