From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlELe-0001SZ-JR for qemu-devel@nongnu.org; Fri, 16 May 2014 05:22:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlELX-0004k9-44 for qemu-devel@nongnu.org; Fri, 16 May 2014 05:22:38 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59956 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlELW-0004jy-Tv for qemu-devel@nongnu.org; Fri, 16 May 2014 05:22:31 -0400 Message-ID: <5375D8D4.4090901@suse.de> Date: Fri, 16 May 2014 11:22:28 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20140514154130.10746.1412.stgit@bahia.local> <20140514154137.10746.94708.stgit@bahia.local> <20140515060425.GA31192@grmbl.mre> <20140515062351.GB14456@redhat.com> <20140515064635.GB31192@grmbl.mre> <20140515090449.2db0cbe0@bahia.local> <537486D2.1060609@suse.de> <20140515120826.050cf6f8@bahia.local> <20140516091424.GJ1941@T430.nay.redhat.com> In-Reply-To: <20140516091424.GJ1941@T430.nay.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 1/8] virtio: add subsections to the migration stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Greg Kurz Cc: Kevin Wolf , Anthony Liguori , "Michael S. Tsirkin" , Juan Quintela , qemu-devel@nongnu.org, Alexander Graf , Stefan Hajnoczi , Amit Shah , Paolo Bonzini Am 16.05.2014 11:14, schrieb Fam Zheng: > On Thu, 05/15 12:08, Greg Kurz wrote: >>>> The main problem I see is that virtio sucks: as you see in patch 8, = we have >>>> to be careful not to call vring or virtqueue stuff before the device= knows >>>> its endianness or it breaks... I need to study how the virtio-bus ge= ts >>>> migrated to ensure the endian section is streamed before the devices= . >>> >>> There is no ordering guarantee. The state needs to be migrated in the >>> device or bus where it sits, if post-load processing is required; i.e= ., >>> if it's in VirtIODevice then something like this series, if it were o= n >>> VirtioBus exclusively (device asking bus for its endianness each time >>> and does not do post-load stuff) then endianness could be migrated as= a >>> new bus section. Not sure if that would help the "broken" state thoug= h? >>> >> >> IIRW the "broken" state was proposed as a per-device property... >=20 > Yes. Sure, and that makes sense, but we do have a 1:1 relation of bus/device, or does virtio-mmio support more? If device doesn't work for some reason, we could (mis)use the bus as fallback then. Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg