[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO"
Date: Tue, 26 May 2015 16:24:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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.


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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]