From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs6Xw-0005JF-Pf for qemu-devel@nongnu.org; Thu, 06 Oct 2016 07:09:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bs6Xs-00015x-F7 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 07:09:03 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs6Xs-00015f-69 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 07:09:00 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u96B8th9038731 for ; Thu, 6 Oct 2016 07:08:59 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 25wjgh0n24-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 06 Oct 2016 07:08:58 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Oct 2016 12:08:45 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id E29231B08023 for ; Thu, 6 Oct 2016 12:10:41 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u96B8htf22544738 for ; Thu, 6 Oct 2016 11:08:43 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u96B8hXZ012574 for ; Thu, 6 Oct 2016 05:08:43 -0600 References: <20160930142003.53232-1-pasic@linux.vnet.ibm.com> <20160930142003.53232-2-pasic@linux.vnet.ibm.com> <2487d687-7fbe-43f4-b9c5-e03b26b2250d@redhat.com> <5b08c569-813b-d805-833a-210e9c8dc436@linux.vnet.ibm.com> <49f37536-0fa7-a38b-a3fa-7b3050001658@redhat.com> <57b04738-7e95-a8c5-d974-0386cbff1419@redhat.com> <20161005142902.GB11921@work-vm> <68ee3bbe-ef83-ce4b-4546-ea27fc2e2ea0@redhat.com> <20161005190006.GF11921@work-vm> From: Halil Pasic Date: Thu, 6 Oct 2016 13:08:42 +0200 MIME-Version: 1.0 In-Reply-To: <20161005190006.GF11921@work-vm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Message-Id: <68c00a6d-b43c-0d4f-e79f-7c19fef33dc6@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH 01/12] virtio: add VIRTIO_DEF_DEVICE_VMSD macro List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Paolo Bonzini Cc: qemu-devel@nongnu.org, "Michael S . Tsirkin" , Gerd Hoffmann , Stefan Hajnoczi , Amit Shah , "Aneesh Kumar K . V" On 10/05/2016 09:00 PM, Dr. David Alan Gilbert wrote: > * Paolo Bonzini (pbonzini@redhat.com) wrote: >> >> >> On 05/10/2016 16:29, Dr. David Alan Gilbert wrote: >>> The virtio-input conversion especially is nice and simple. >>> The only weird case is virtio-gpu, and well virtio-gpu is the one that's >>> odd here (compared to the rest of virtio). >> >> Though virtio-gpu would be the one that could become nicer without the >> macros. :) > > Yes, it would. > >> What I don't like about the macros is that they don't allow you to >> extend the VMStateDescription. [..] >> However, if you agree with Halil your >> opinion counts more. > > Well I think Halil's stuff moves it in the right direction; > with everything in VIRTIO_DEF_DEVICE_VMSD it means we can move things > out of virtio_load/save and into corresponding members in VIRTIO_DEF_DEVICE_VMSD's > .fields array (before or after VMSTATE_VIRTIO_FIELD) without having > to change any of the devices. Eventually virtio_load/save disappear. > I think this would end up messy if we want to preserve the current behavior of virtio_load/save, and more importantly compatibility. AFAIU we would have a 'synthetic' field for the configuration/transport migration first, then a field dealing with the state in VirtIODevice excluding config_vector and subsections (the state of virtio-core), then we would have a sequence of fields dealing with the device specific state of the transport agnostic virtio device (e.g. virtio-net, virtio-gpu) that is emulate load/save from VirtIODeviceClass, then we would have to take care of the virtio core subsections and possibly device specific subsections (or have yet another synthetic field for device specific subsections). This is actually the first thing I wanted to do in response to "[RFC 0/6] converting some of virtio to VMState" but after some thinking, concluded for myself that it will end up too messy and way less readable that what Dave did there, without any real gain to make the increased complexity justified. Or am I mistaken here? Halil