Re: [Qemu-devel] [Spice-devel] seamless migration with spice

[Gerd Hoffmann]

  Hi,

> The problem with (b) is, that iirc the way b was implemented in the past
> was still the big blob approach, but then pass the blob through the client,
> which means an evil client could modify it, causing all sorts of
> "interesting"
> behavior inside spice-server. Since we're re-implementing this to me the
> send a blob through the client approach is simply not acceptable from a
> security pov, also see my previous mail in this thread.

Agree.  It should be a normal spice message which goes through the spice
marshaller for parsing & sanity checking.

> I disagree. Note that there is more info to send over then just which
> surfaces / images are cached by the client. There also is things like
> partial complete agent channel messages, including how much bytes must
> be read
> to complete the command, etc.

Is there a complete list of the session state we need to save?

> IMHO (b) would only be acceptable if the data send through the client stops
> becoming a blob.

Using (a) to send a blob isn't better.

> Instead the client could simply send a list of all
> surface ids,
> etc. which it has cached after it connects to / starts using the new
> host. Note
> that the old hosts needs to send nothing for this, this is info the
> client already
> has, also removing the need for synchronization.

Yes, some session state is known to the client anyway so we don't need a
source <-> target channel for them.

> As for certain other
> data, such
> as (but not limited to) partially parsed agent messages, these should be
> send through the regular vmstate methods IMHO.

That isn't easy to handle via vmstate, at least as soon as this goes
beyond a fixed number of fields aka 'migrate over this struct for me'.
Think multiple spice clients connected at the same time.

> 1) Do (a), sending everything that way
> 2) Do (a) sending non client state that way; and
>    let the client send state like which surfaces it has cached
>    when the new session starts.

I think we have to look at each piece of state information needed by the
target and look how to handle this best.

cheers,
  Gerd