Re: [Qemu-devel] [PATCH v2 10/17] block: define get_block_status return value

[Peter Lieven <pl@kamp.de>]

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