From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45997)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1V07YH-0006Kl-Ps
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 06:04:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1V07YC-0005N2-EH
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 06:04:41 -0400
Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:58306 helo=mx01.kamp.de)
	by eggs.gnu.org with smtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1V07YC-0005Ma-2y
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 06:04:36 -0400
Message-ID: <51E90F28.9050409@kamp.de>
Date: Fri, 19 Jul 2013 12:04:24 +0200
From: Peter Lieven <pl@kamp.de>
MIME-Version: 1.0
References: <1373992168-26043-1-git-send-email-pbonzini@redhat.com>
	<1373992168-26043-11-git-send-email-pbonzini@redhat.com>
	<51E8E124.3050500@kamp.de> <51E90DD3.8030600@redhat.com>
In-Reply-To: <51E90DD3.8030600@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 10/17] block: define get_block_status
	return value
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com

On 19.07.2013 11:58, Paolo Bonzini wrote:
> Il 19/07/2013 08:48, Peter Lieven ha scritto:
>>> -    return bdrv_get_block_status(bs, sector_num, nb_sectors, pnum);
>>> +    int64_t ret = bdrv_get_block_status(bs, sector_num, nb_sectors,
>>> pnum);
>>> +    return
>>> +        (ret & BDRV_BLOCK_DATA) ||
>>> +        ((ret & BDRV_BLOCK_ZERO) && !bdrv_has_zero_init(bs));
>> i do also not understand the "((ret & BDRV_BLOCK_ZERO) &&
>> !bdrv_has_zero_init(bs))";
>> if a block is unallocated and reads as zero, but the device lacks zero
>> init, it is declared as allocated with this, isn't it?
> Thinking more about it, I would say it is a bugfix.
>
> If a block is unallocated and reads as zero, but the device lacks zero
> init, the block contents have changed since the guest was created.  Thus
> the guest might well be relying on the zero content of the block, and it
> should be treated as allocated.
i was told that has_zero_init sole task is to report the state
of the device right after iscsi_create(). using it for r/w in qemu
might be a misuse.

>
> In any case, better safe than sorry---if in doubt, the conservative
> answer is always to return 1, and callers who want more precise
> information can use bdrv_get_block_status.
you mean for every call to the deprecated bdrv_is_allocate()?

Peter