From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEKov-0002oK-O5 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 06:14:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEKor-0002nw-39 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 06:14:13 -0400 Received: from [199.232.76.173] (port=47190 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEKoq-0002nt-V2 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 06:14:09 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43451) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MEKoq-00051L-IK for qemu-devel@nongnu.org; Wed, 10 Jun 2009 06:14:08 -0400 Date: Wed, 10 Jun 2009 13:11:02 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCHv3 12/13] qemu: virtio save/load bindings Message-ID: <20090610101102.GI6844@redhat.com> References: <20090605102426.GM26770@redhat.com> <20090609174554.GD19375@poweredge.glommer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090609174554.GD19375@poweredge.glommer> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Carsten Otte , kvm@vger.kernel.org, Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook , Avi Kivity On Tue, Jun 09, 2009 at 02:45:54PM -0300, Glauber Costa wrote: > duplicated save config. > > > diff --git a/hw/virtio.h b/hw/virtio.h > > index 04a3c3d..ce05517 100644 > > --- a/hw/virtio.h > > +++ b/hw/virtio.h > > @@ -72,6 +72,10 @@ typedef struct VirtQueueElement > > > > typedef struct { > > void (*notify)(void * opaque, uint16_t vector); > > + void (*save_config)(void * opaque, QEMUFile *f); > > + void (*save_queue)(void * opaque, int n, QEMUFile *f); > > + int (*load_config)(void * opaque, QEMUFile *f); > > + int (*load_queue)(void * opaque, int n, QEMUFile *f); > > } VirtIOBindings; > > > So, what's the overall effect on a virtual machine that gets migrated, > of a certain device not implementing one of those functions? Those are implemented by a transport (e.g. virtio_pci) not the device. > Will it work? Will it break? It will work - assuming there's nothing transport-specific you need to save and load. If there is - this patch is not breaking anything that isn't already broken ... -- MST