On Wed, Jun 29, 2011 at 12:25:00PM +0200, Gerd Hoffmann wrote:
On 06/29/11 11:21, Alon Levy wrote:
On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote:
Hi,
I think it will receive them after migration, since the command ring
was stored.
Our confusion here is because you think there is still seemless migration.
Unfortunately
it doesn't work right now, unless you plan to fix it the only form of migration
right
now is switch-host, and for that those commands will be lost, the new
connection will receive
images for each surface. If you treat the client as seemless you are completely
right.
The spice server needs this too so it can render the surfaces
correctly before sending the surface images to the client (or send
the old surfaces and the commands on top of that).
That is one difference between qemu migration and S3 state: For qemu
migration it is no problem to have unprocessed commands in the
rings, they will simply be processed once the spice server state is
restored. When the guest driver restores the state when it comes
back from S3 it needs the command rings to do so, thats why they
must be flushed before entering S3 ...
You mean it needs the command rings to be empty before, since they are lost
during the reset, right?
One more reason. Wasn't aware there is a reset anyway, was thinking
hah. The reset is the whole mess.. otherwise S3 would have been trivial,
and actually disabling the reset was the first thing we did, but of course
it doesn't solve S4 in that case.
more about the command ordering. Without reset spice-server would
first process the old commands (which may reference non-existing
surfaces), then the new commands which re-recreate all state, which
is simply the wrong order. With reset the old commands just get
lost which causes rendering bugs.
Is it an option to have the driver just remove the commands from the
ring (and resubmit after resume)? I suspect it isn't as there is no
race-free way to do that, right?
Right - the whole ring assumes that the same side removes. of course we
can add an IO for that (two - FREEZE and UNFREEZE). But I think this is
the wrong approach. Instead, rendering all the commands, and dropping the
wait for the client. Right now if we flush we do actually wait for the client,
but I plan to remove this later. (we do this right now for update_area as
well and that's much higher frequency).
cheers,
Gerd