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

[Peter Lieven]

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