Hi,
On 16 August 2010 22:26, Janne Huttunen jahut...@gmail.com wrote:
Yes, your version works (both on paper and in practice). I'm not
quite sure I like the way it breaches the apparent abstraction
of the FIFO handling routines (if you can call it that) or the
way it first gives FIFO slots
I came up with this version, it kind of reverses the logic of your
patch but reuses the _items function (renamed _length), please
see if it looks ok and possibly even works.
[sorry about the delay, I was out of office for a while]
Yes, your version works (both on paper and in practice). I'm
From: Andrzej Zaborowski balr...@gmail.com
Hi Janne,
I came up with this version, it kind of reverses the logic of your
patch but reuses the _items function (renamed _length), please
see if it looks ok and possibly even works.
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 12bff48..464f8bc
Sorry, tried to use get-send-email but haven't tested first.
On 23 July 2010 03:35, bal...@openstreetmap.pl wrote:
From: Andrzej Zaborowski balr...@gmail.com
...
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
Hi,
On 21 July 2010 13:17, Janne Huttunen jahut...@gmail.com 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
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
On 21 July 2010 14:14, Janne Huttunen jahut...@gmail.com wrote:
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
I see no way to tell whether the guest is currently in the middle of
writing a command. So it seems the only way to check is to peek the
first word in the fifo (which *is* written entirely before a NEXT_CMD
update) and look up the expected command length, and then check
whether enough data is
Here's an experiment for sanity checking the lengths and leaving
the command in the FIFO if it is not complete. It fixes the
problem for me (running it right now), but I agree that it's not
very elegant to look at :-/ .
And here's another version with couple of stupid bugs removed
(it
10 matches
Mail list logo
