On Mon, Jun 11, 2012 at 09:25:46AM +0200, Gerd Hoffmann wrote: > Hi, > > > I'm still not a big fan of the concept of server data going through the > > client, this means the server > > will need to seriously sanity check what it receives to avoid > > potentially new attacks on it. > > > > I'm wondering why not do the following: > > > > 1) spicevmc device gets a savevm call, tell spice-server to send a > > message to the client telling it > > to stop sending more data to *this* server. > > 2) client sends an ack in response to the stop sending data server > > 3) server waits for ack. > > 4) savevm continues only after ack, which means all data which was in > > flight has been received. > > Isn't going to fly. The extra roundtrip time adds to the guests > downtime, we will not get that upstream. > > I think we don't need that though. The guest -> client path isn't > critical, we can just send any pending buffers before sending the > MIGRATE_MSG. > > The client -> guest messages can be handled like this: > > * The client keeps a copy of the last few messages. This is a lot of work for infrequent migration. I don't think the silly buffer passing is that silly compared to this. Also, this is not always enough, like you say below - heuristic for the amount of messages to keep. On the other hand the buffer passing scheme is always correct. > * On migration the server informs the client which message was > the last one committed to the guest. > * After migration the client can simply resend messages if needed. > > We could also extend the spicevmc protocol and have the spice server > explicitly ack each message after it was passed successfully to the > guest. Then the client can just free the messages once acked instead of > using heuristics for the number of messages to keep. We also don't have > any special migration state then, after migration the client simply > replays all the (un-acked) messages it has. > > This also removes the somewhat silly buffer passing: data send from the > client to the src spice server (but not yet passed to the guest) is > passed from src spice server back to the client so it can forward it to > the dst spice server ... > > >> - list of off-screen surfaces ids that have been sent to the client, > >> and their lossy region. > >> By keeping this data we will avoid on-demand resending surfaces that > >> already exist on the client side. > > > > The client already knows which off-screen surfaces ids it has been > > received, so it can just > > send these to the new server without having to receive them from the old > > one first. > > Agree. Any state which the client knows anyway doesn't need to be part > of the MIGRATE_DATA. > > cheers, > Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel