From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXjuN-0001mE-NB for qemu-devel@nongnu.org; Sat, 27 Sep 2014 00:47:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXjuI-00019r-JF for qemu-devel@nongnu.org; Sat, 27 Sep 2014 00:46:59 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:38699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXjuG-00019N-Q5 for qemu-devel@nongnu.org; Sat, 27 Sep 2014 00:46:54 -0400 From: "Gonglei (Arei)" Date: Sat, 27 Sep 2014 04:46:23 +0000 Message-ID: <33183CC9F5247A488A2544077AF1902086DDC62B@SZXEMA503-MBS.china.huawei.com> References: <1411721147-11712-1-git-send-email-arei.gonglei@huawei.com> <20140926162125.71ea6598.cornelia.huck@de.ibm.com> In-Reply-To: <20140926162125.71ea6598.cornelia.huck@de.ibm.com> Content-Language: zh-CN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH RESEND 0/9] virtio: fix virtio child recount in transports List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: "Huangweidong (C)" , "mst@redhat.com" , "armbru@redhat.com" , Luonengjun , "agraf@suse.de" , "qemu-devel@nongnu.org" , "borntraeger@de.ibm.com" , "stefanha@redhat.com" , "pbonzini@redhat.com" , "Huangpeng (Peter)" , "rth@twiddle.net" Hi, > > > > virtio-$device-{pci, s390, ccw} all duplicate the > > qdev properties of their virtio child. This approach does > > not work well with string or pointer properties since we > > must be careful about leaking or double-freeing them. > > > > Use the QOM alias property to forward property accesses to the > > VirtIORNG child. This way no duplication is necessary. > > > > For their child, object_initialize() leaves the object with a refcount = of 1. > > object_property_add_child() adds its own reference which is dropped > > again when the property is deleted. > > > > The upshot of this is that we always have a refcount >=3D 1. Upon hot > > unplug the virtio-$device child is not finalized! > > > > Drop our reference after the child property has been added to the > > parent. > > > > Attention please: > > As Michael's comments, the patches will introduce regresion about > > "-device FOO,help", which had been fixed by my other patch series: > > [PATCH v2 0/7] add description field in ObjectProperty and PropertyIn= fo > struct > > http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg04908.html > > > > Acknowledgements: > > I copied Stefan's commit c5d49db message about virtio-blk which > > summarized reasons very well, I cannot agree more with him. > > Holp Stefan do not mind, thanks! > > > > Please review, Thanks a lot! >=20 > Do you have a git branch for quick testing? >=20 Sorry, I havn't. :( =20 I worked this in the environment of my company, then send patches. Would you apply those patches based qemu master by 'git am' ?=20 Thanks! > > -Gonglei > > > > Gonglei (9): > > virtio-net: use aliases instead of duplicate qdev properties > > virtio: fix virtio-net child refcount in transports > > virtio/vhost scsi: use aliases instead of duplicate qdev properties > > virtio/vhost-scsi: fix virtio-scsi/vhost-scsi child refcount in > > transports > > virtio-serial: use aliases instead of duplicate qdev properties > > virtio-serial: fix virtio-serial child refcount in transports > > virtio-rng: use aliases instead of duplicate qdev properties > > virtio-rng: fix virtio-rng child refcount in transports > > virtio-balloon: fix virtio-balloon child refcount in transports > > > > hw/s390x/s390-virtio-bus.c | 16 ++++++++++------ > > hw/s390x/virtio-ccw.c | 18 +++++++++++------- > > hw/virtio/virtio-pci.c | 18 +++++++++++------- > > 3 files changed, 32 insertions(+), 20 deletions(-) >=20 > One thing I noticed is that the various devices end up with similar > code in the end: >=20 > object_initialize(&dev->vdev, sizeof(dev->vdev), TYPE_WHATEVER); > object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), > NULL); > object_unref(OBJECT(&dev->vdev)); > qdev_alias_all_properties(DEVICE(&dev->vdev), obj); >=20 > Would it make sense to add a helper function for that? Yes. I think it make sense. Maybe I can add a helper function in virtio.c, named virtio_backend_init(). Agree? Thanks! Best regards, -Gonglei