From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: KVM call agenda for June 28 Date: Thu, 30 Jun 2011 14:39:41 +0200 Message-ID: <4E0C6E8D.9040705@redhat.com> References: <20110628194106.GA17443@amt.cnet> <4E0ADAE0.6040204@redhat.com> <20110629154134.GA6631@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , quintela@redhat.com, KVM devel mailing list , qemu-devel@nongnu.org, Chris Wright , Dor Laor , Avi Kivity To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50395 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031Ab1F3Mgv (ORCPT ); Thu, 30 Jun 2011 08:36:51 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Am 30.06.2011 13:48, schrieb Stefan Hajnoczi: > On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti wrote: >> On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote: >>> In the future we could add a 'base' argument to block_stream. If base >>> is specified then data contained in the base image will not be copied. >> >> This is a present requirement. > > It's not one that I have had in the past but it is a reasonable requirement. > > One interesting thing about this requirement is that it makes > copy-on-read seem like the wrong primitive for image streaming. If > there is a base image which should not be streamed then a plain loop > that calls bdrv_is_allocated_chain(bs, base, sector, &pnum) and copies > sectors into bs is more straightforward than passing base to a > copy-on-read operation somehow (through a variable that stashes the > base away somewhere?). You don't even have to look at the implementation to say that COR is a useful optimisation. It basically means that you reuse data read by the guest instead of reading it a second time in your loop. (And this is equally true for block copy and image streaming) If this means adding a new field in BlockDriverState, so be it. Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcGbH-0008CV-G6 for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:44:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcGbF-0007Xg-Hj for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:44:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcGUE-0006eD-Bu for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:36:50 -0400 Message-ID: <4E0C6E8D.9040705@redhat.com> Date: Thu, 30 Jun 2011 14:39:41 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20110628194106.GA17443@amt.cnet> <4E0ADAE0.6040204@redhat.com> <20110629154134.GA6631@amt.cnet> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for June 28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Chris Wright , Marcelo Tosatti , KVM devel mailing list , quintela@redhat.com, Dor Laor , qemu-devel@nongnu.org, Avi Kivity Am 30.06.2011 13:48, schrieb Stefan Hajnoczi: > On Wed, Jun 29, 2011 at 4:41 PM, Marcelo Tosatti wrote: >> On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote: >>> In the future we could add a 'base' argument to block_stream. If base >>> is specified then data contained in the base image will not be copied. >> >> This is a present requirement. > > It's not one that I have had in the past but it is a reasonable requirement. > > One interesting thing about this requirement is that it makes > copy-on-read seem like the wrong primitive for image streaming. If > there is a base image which should not be streamed then a plain loop > that calls bdrv_is_allocated_chain(bs, base, sector, &pnum) and copies > sectors into bs is more straightforward than passing base to a > copy-on-read operation somehow (through a variable that stashes the > base away somewhere?). You don't even have to look at the implementation to say that COR is a useful optimisation. It basically means that you reuse data read by the guest instead of reading it a second time in your loop. (And this is equally true for block copy and image streaming) If this means adding a new field in BlockDriverState, so be it. Kevin