Il 16/07/2013 09:54, Peter Lieven ha scritto: > On 16.07.2013 09:19, Paolo Bonzini wrote: >> Il 16/07/2013 08:47, Peter Lieven ha scritto: >>>> @@ -2977,7 +2977,11 @@ static int64_t coroutine_fn >>>> bdrv_co_get_block_status(BlockDriverState *bs, >>>> if (!bs->drv->bdrv_co_get_block_status) { >>>> *pnum = nb_sectors; >>>> - return BDRV_BLOCK_DATA; >>>> + ret = BDRV_BLOCK_DATA; >>>> + if (bs->drv->protocol_name) { >>>> + ret |= BDRV_BLOCK_OFFSET_VALID | (sector_num * >>>> BDRV_SECTOR_SIZE); >>>> + } >>>> + return ret; >>>> } >>>> ret = bs->drv->bdrv_co_get_block_status(bs, sector_num, >>>> nb_sectors, pnum); >>> I am curious if this is right. Doesn't this mean we say that at offset >>> sector_num * BDRV_SECTOR_SIZE are nb_sectors of linear data? This is >>> something we do not know for sure. >> Only for protocols. In this case, we do know, or format=raw wouldn't >> work. This is not propagated up to the actual BDS for the image, except >> for format=raw. > If bs->drv->protocol_name is only != NULL if format=raw, I am > fine with this.
No, bs->drv->protocol_name is only != NULL if it is a protocol (like file or iscsi) rather than a format (like raw or qcow2). :) But the user will never call bdrv_co_get_block_status on a protocol (bs->file, roughly), only on a format (bs); and this information is only passed from bs->file to bs for format=raw. Other formats compute the offsets themselves. Paolo