qemu-devel
[Top][All Lists]
Advanced

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

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


From: andrzej zaborowski
Subject: Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
Date: Wed, 21 Jul 2010 14:33:00 +0200

On 21 July 2010 14:14, Janne Huttunen <address@hidden> 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 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, okay, I had expected the driver to not update NEXT_CMD until it's
done with writing the current command, but it does update after every
word.  I'd say this is wrong, but we probably need to handle it in
qemu.

The sequence is not atomic, although with TCG it may turn out to be
atomic depending on how the code was compiled and where the page
boundary is... there are only RAM accesses so they shouldn't cause a
vmexit.  No idea about KVM.

>
>> 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?

Not that I know.

>
> "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?

The timers are also updated from the select loop.. but in theory yes,
it can go off in between the WriteWordToFIFO calls and we need to take
that into account.

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 in the FIFO.  Do you want to implement this?

Cheers



reply via email to

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