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

[Paolo Bonzini]

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()".

>> 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()?

Of course I'm not advocating returning 1 for every call.  But if the
semantic isn't clear, I prefer to err on the safe side.

Paolo