Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO"

[Max Reitz <mreitz@redhat.com>]

On 26.05.2015 16:22, Kevin Wolf wrote:
> Am 21.05.2015 um 08:42 hat Fam Zheng geschrieben:
>> It blocks device IO.
> What I'm missing here is a description of the case that it protects
> against. Blocking device I/O doesn't sound like a valid thing to want
> per se, but it might be true that we need it as long as we don't have
> the "real" op blockers that Jeff is working on. However, as long as you
> don't say why you want that, I can't say whether it's true or not.
>
> And of course, it doesn't block anything yet after this patch, it's just
> set or cleared without any effect. In fact, it seems that even at the
> end of the series, there is no bdrv_op_is_blocked() call that checks for
> BLOCK_OP_TYPE_DEVICE_IO. Is this intentional?

Probably yes, because patches 2 and 3 introduce a notifier for when op 
blockers are set up and removed. This is used by virtio-blk and 
virtio-scsi to pause and unpause device I/O, respectively.

Max

>> All bdrv_op_block_all/blk_op_block_all callers are taken care of:
>>
>> - virtio_blk_data_plane_create
>> - virtio_scsi_hotplug
>>
>>    Device creation, unblock it.
>>
>> - bdrv_set_backing_hd
>>
>>    Backing hd is not used by device, so blocking is OK.
> If the backing file becomes the active layer after committing,
> bdrv_swap() will keep the blockers of the overlay, so that the image
> doesn't have the device I/O blocker any more. Correct?
>
>> - backup_start
>>
>>    Blocking target when backup is running, unblock it.
>>
>> - mirror_complete
>>
>>    Blocking s->to_replace until mirror_exit, OK.
>>
>> - block_job_complete
>>
>>    The block job may be long running. Unblock it.
>>
>> - init_blk_migration
>>
>>    The block migration may be long running, Unblock it.
>>
>> Signed-off-by: Fam Zheng <famz@redhat.com>
> Kevin