From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S71qC-0007b9-RM for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:47:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S71q6-0000vK-H9 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:46:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S71q6-0000v8-8z for qemu-devel@nongnu.org; Mon, 12 Mar 2012 05:46:50 -0400 Message-ID: <4F5DC604.9010702@redhat.com> Date: Mon, 12 Mar 2012 10:46:44 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4F5CA590.1000605@redhat.com> <4F5CB429.4000907@codemonkey.ws> <20120311152528.GD7273@garlic.redhat.com> <4F5CC692.7050002@codemonkey.ws> <4F5DAC69.6010002@redhat.com> <4F5DB906.2030508@redhat.com> In-Reply-To: <4F5DB906.2030508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: "spice-devel@freedesktop.org" , qemu-devel , Anthony Liguori 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