On 07/16/2013 10:29 AM, Paolo Bonzini wrote: > Define the return value of get_block_status. Bits 0, 1, 2 and 9-62 > are valid; bit 63 (the sign bit) is reserved for errors. Bits 3-7
bits 3-8, actually
> are left for future extensions.
>
> The return code is compatible with the old is_allocated API: returning
> just 0 or 1 (aka BDRV_BLOCK_DATA) will not cause any behavioral change
> in clients of is_allocated. We will return more precise information
> in the next patches.
>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
> v1->v2: improved comment
>
> block.c | 7 +++++--
> include/block/block.h | 26 ++++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> +++ b/include/block/block.h
> @@ -81,6 +81,32 @@ typedef struct BlockDevOps {
> #define BDRV_SECTOR_SIZE (1ULL << BDRV_SECTOR_BITS)
> #define BDRV_SECTOR_MASK ~(BDRV_SECTOR_SIZE - 1)
>
> +/* BDRV_BLOCK_DATA: data is read from bs->file or another file
> + * BDRV_BLOCK_ZERO: sectors read as zero
> + * BDRV_BLOCK_OFFSET_VALID: sector stored in bs->file as raw data
> + *
> + * If BDRV_BLOCK_OFFSET_VALID is set, bits 9-62 represent the offset in
> + * bs->file where sector data can be read from as raw data.
And handy that the offset happens to be aligned to the current 512
sector size, so you can just mask without shifting to get an aligned
offset to the start of the sector.
> + *
> + * DATA == 0 && ZERO == 0 means that data is read from backing_hd if present.
> + *
> + * DATA ZERO OFFSET_VALID
> + * t t t sectors read as zero, bs->file is zero at offset
> + * t f t sectors read as valid from bs->file at offset
> + * f t t sectors preallocated, read as zero, bs->file not
> + * necessarily zero at offset
> + * f f t sectors preallocated but read from backing_hd,
> + * bs->file contains garbage at offset
> + * t t f sectors preallocated, read as zero, unknown offset
> + * t f f sectors read from unknown file or offset
> + * f t f not allocated or unknown offset, read as zero
> + * f f f not allocated or unknown offset, read from
> backing_hd
Makes sense.
No further comments beyond other reviewers, if you want to add:
Reviewed-by: Eric Blake <ebl...@redhat.com>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
