From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0AOp-0002qD-J9 for qemu-devel@nongnu.org; Fri, 19 Jul 2013 09:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0AOm-0003UR-8c for qemu-devel@nongnu.org; Fri, 19 Jul 2013 09:07:07 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:59723 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1V0AOl-0003OF-Uo for qemu-devel@nongnu.org; Fri, 19 Jul 2013 09:07:04 -0400 Message-ID: <51E939F2.3020009@kamp.de> Date: Fri, 19 Jul 2013 15:06:58 +0200 From: Peter Lieven 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> <51E90F28.9050409@kamp.de> <51E92D5B.6020600@redhat.com> In-Reply-To: <51E92D5B.6020600@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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 19.07.2013 14:13, Paolo Bonzini wrote: > Il 19/07/2013 12:04, Peter Lieven ha scritto: >> 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. > Yes, and here I'm using it exactly for that task. I'm saying "treat a > zero block as allocated if it wasn't zero right after _create()". If it is zero and allocated the API should return only BDRV_BLOCK_DATA and if it is zero and unallocated only BDRV_BLOCK_ZERO or not? What I mean is the new API shouldn't change the behaviour of the old bdrv_is_allocated(). It would have returned (ret & BDRV_BLOCK_DATA) regardless if BDRV_BLOCK_ZERO or not. Peter