From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzRJA-000704-5Z for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:58:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzRJ8-0002Pb-56 for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:58:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzRJ7-0002PJ-SB for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:58:14 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6HCwC22013747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Jul 2013 08:58:12 -0400 Date: Wed, 17 Jul 2013 14:58:10 +0200 From: Kevin Wolf Message-ID: <20130717125810.GI2458@dhcp-200-207.str.redhat.com> References: <1374054136-28741-1-git-send-email-famz@redhat.com> <1374054136-28741-11-git-send-email-famz@redhat.com> <51E68FBC.10200@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E68FBC.10200@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Fam Zheng , hbrock@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, imain@redhat.com, stefanha@redhat.com Am 17.07.2013 um 14:36 hat Paolo Bonzini geschrieben: > Il 17/07/2013 11:42, Fam Zheng ha scritto: > > This option allows overriding backing hd of drive. If the target drive > > exists, it's referenced as the backing file and refcount incremented. > > > > Example: > > qemu-system-x86_64 -drive \ > > file.filename=foo.qcow2,if=none,id=foo \ > > -drive file=bar.qcow2,backing=foo > > I guess this is where we need the soft reference. > > This has a _lot_ of potential for misuse, I think Kevin bashed me and > Federico very heavily when we tried to do something similar. Not sure what exactly I "bashed" you for, but I think this is really the right thing to do, and it's the general direction we're headed for with blockdev-add. The user manages his BlockDriverStates and connects them as he sees fit. The defaults of qemu are only used when the user doesn't override them (and libvirt is going to override most to use fd passing). My expectation is, admittedly, that it's hard to get right from where we stand today, because of the coupling of BlockDriverStates with guest devices, but with the refcounting patches (which I haven't reviewed yet), maybe one of the biggest concerns is addressed. This is basically restarting the discussion where I suggested to give the targets of a block job names so that they can be reused. It's about the same kind of misuse that becomes possible and that we need to protect against. Kevin