From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgB9t-00021A-Cp for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgB9n-0005mF-77 for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:29:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgB9m-0005m7-VK for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:29:47 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9KBTkLJ009851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 20 Oct 2014 07:29:46 -0400 Date: Mon, 20 Oct 2014 13:29:44 +0200 From: Kevin Wolf Message-ID: <20141020112943.GG3585@noname.redhat.com> References: <1413359710-2799-1-git-send-email-quintela@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413359710-2799-1-git-send-email-quintela@redhat.com> Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org, laine@redhat.com, lcapitulino@redhat.com Am 15.10.2014 um 09:55 hat Juan Quintela geschrieben: > Hi > > by popular demand, and after too many time, this series. This is an > RFC to know what people think about how to use them, the interface > proposed, whatever. > [...] > > Kevin: You asked for optional sections in the past for the block > layer, would this proposal be enough for you? I know I've asked in more than one occasion, and of course I don't remember all the details any more. Anyway, I remember two cases offhand: * qcow2 with patches like Delayed COW keeps internal block layer state in memory that might need to be migrated. This series looks fine for this case in principle, we'd just need to find a way to distinguish the affected BlockDriverStates. We can probably take a node-name if it exists (with Jeff's auto-naming patches not a problem, because then it would always exist) How do devices solve this? Do they use something like a qdev path to identify to which device a given section belongs? * When a VM is stopped after an I/O error, we need to migrate the information about pending requests (bdrv_drain_all doesn't complete the failed requests). Currently we do this in device code, but it would be very nice to make this common block layer functionality. The problem here is that bdrv_aio_readv/writev get an opaque pointer back to the device, which of course becomes meaningless during migration. So this one is tricky even if we have optional top-level sections. Kevin