From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55014)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VBOH9-0000Ko-B6
	for qemu-devel@nongnu.org; Mon, 19 Aug 2013 08:09:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VBOH3-0002pK-96
	for qemu-devel@nongnu.org; Mon, 19 Aug 2013 08:09:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36000)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1VBOH2-0002ov-W9
	for qemu-devel@nongnu.org; Mon, 19 Aug 2013 08:09:29 -0400
Date: Mon, 19 Aug 2013 14:09:24 +0200
From: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20130819120924.GC3591@stefanha-thinkpad.redhat.com>
References: <1375690310-9051-1-git-send-email-asias@redhat.com>
	<CAJSP0QX7HRXZe5_b1KF=N0=q8igH4auQnT4mfRXYKtbvyeGLoA@mail.gmail.com>
	<20130819063614.GA14101@hj.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130819063614.GA14101@hj.localdomain>
Subject: Re: [Qemu-devel] [PATCH] block: Produce zeros when protocols
 reading beyond end of file
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Asias He <asias@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>

On Mon, Aug 19, 2013 at 02:36:14PM +0800, Asias He wrote:
> On Fri, Aug 16, 2013 at 10:41:36AM +0200, Stefan Hajnoczi wrote:
> > On Mon, Aug 5, 2013 at 10:11 AM, Asias He <asias@redhat.com> wrote:
> > A simple but ugly way to fix this is for block.c to also have a
> > ->zero_beyond_eof flag which enables the behavior you are adding.
> > qcow2_load_vmstate() would disable ->zero_beyond_eof temporarily in
> > addition to enabling ->growable.
> 
> I am wondering why the ->growable logic is introduced in the first
> place.  Adding yet another this kind of flag looks realy ugly ;(

bs->growable serves two functions:

1. It means you can read/write beyond the end of the file, for example,
   when creating a new image file.  Normally BlockDriverState rejects
   requests beyond the EOF.

2. qcow2 uses it as a hack to implement the vmstate area after the end
   of regular guest data.  This is the ugly part but it always worked up
   until now.

#1 is a legitimate use case.  You don't always know how big the file
will end up so it's much more convenient to grow on demand, instead of
having to bdrv_truncate() all the time.

#2 is hacky but hard to solve without duplicating the bounce buffer and
coroutine wrapping logic in bdrv_pread() (Kevin has suggested calling
bdrv_co_readv() internally instead of bdrv_pread()).

Stefan