From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S74et-0005HT-Cu for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:47:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S74eM-00066N-62 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:47:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S74eL-000661-UW for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:46:54 -0400 Message-ID: <4F5DF074.2030305@redhat.com> Date: Mon, 12 Mar 2012 14:47:48 +0200 From: Yonit Halperin 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> <4F5DC604.9010702@redhat.com> In-Reply-To: <4F5DC604.9010702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Gerd Hoffmann Cc: Anthony Liguori , Hans de Goede , qemu-devel , "spice-devel@freedesktop.org" On 03/12/2012 11:46 AM, Gerd Hoffmann wrote: > 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. > Gerd/Hans, Can you explain/exemplify, why sending data as a blob (either by (a) or (b)), that is verified only by the two ends that actually use it, is a problem? Lets say the client/qemu are completely aware of the migration data, what prevent it from harming it then? >> 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 > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel