v4 -> v5:
- vhost: check queue state in the vhost_dev_set_log routine
tests/qtest/vhost-user-test: prepare the tests for adding new
dev class
tests/qtest/vhost-user-test: add support for the
vhost-user-blk device
tests/qtest/vhost-user-test: add migrate_reconnect test
Reviewed-by: Raphael Norwitz
- Update qtest, by merging vhost-user-blk "if" case with the
virtio-blk case.
v3 -> v4:
- vhost: recheck dev state in the vhost_migration_log routine
Reviewed-by: Raphael Norwitz
- vhost: check queue state in the vhost_dev_set_log routine
Use "continue" instead of "break" to handle non-initialized
virtqueue case.
v2 -> v3:
- update commit message for the
"vhost: recheck dev state in the vhost_migration_log routine" commit
- rename "started" field of the VhostUserBlk structure to
"started_vu", so there will be no confustion with the VHOST started
field
- update vhost-user-test.c to always initialize nq local variable
(spotted by patchew)
v1 -> v2:
- add comments to connected/started fields in the header file
- move the "s->started" logic from the vhost_user_blk_disconnect
routine to the vhost_user_blk_stop routine
Reference e-mail threads:
- https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg01509.html
- https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05241.html
If vhost-user daemon is used as a backend for the vhost device, then we
should consider a possibility of disconnect at any moment. There was a general
question here: should we consider it as an error or okay state for the
vhost-user
devices during migration process?
I think the disconnect event for the vhost-user devices should not break the
migration process, because:
- the device will be in the stopped state, so it will not be changed
during migration
- if reconnect will be made the migration log will be reinitialized as
part of reconnect/init process:
#0 vhost_log_global_start (listener=0x563989cf7be0)
at hw/virtio/vhost.c:920
#1 0x000056398603d8bc in listener_add_address_space
(listener=0x563989cf7be0,
as=0x563986ea4340 <address_space_memory>)
at softmmu/memory.c:2664
#2 0x000056398603dd30 in memory_listener_register (listener=0x563989cf7be0,
as=0x563986ea4340 <address_space_memory>)
at softmmu/memory.c:2740
#3 0x0000563985fd6956 in vhost_dev_init (hdev=0x563989cf7bd8,
opaque=0x563989cf7e30, backend_type=VHOST_BACKEND_TYPE_USER,
busyloop_timeout=0)
at hw/virtio/vhost.c:1385
#4 0x0000563985f7d0b8 in vhost_user_blk_connect (dev=0x563989cf7990)
at hw/block/vhost-user-blk.c:315
#5 0x0000563985f7d3f6 in vhost_user_blk_event (opaque=0x563989cf7990,
event=CHR_EVENT_OPENED)
at hw/block/vhost-user-blk.c:379
The first patch in the patchset fixes this issue by setting vhost device to the
stopped state in the disconnect handler and check it the vhost_migration_log()
routine before returning from the function.
qtest framework was updated to test vhost-user-blk functionality. The
vhost-user-blk/vhost-user-blk-tests/migrate_reconnect test was added to
reproduce
the original issue found.
Dima Stepanov (7):
vhost: recheck dev state in the vhost_migration_log routine
vhost: check queue state in the vhost_dev_set_log routine
tests/qtest/vhost-user-test: prepare the tests for adding new dev
class
tests/qtest/libqos/virtio-blk: add support for vhost-user-blk
tests/qtest/vhost-user-test: add support for the vhost-user-blk device
tests/qtest/vhost-user-test: add migrate_reconnect test
tests/qtest/vhost-user-test: enable the reconnect tests
hw/block/vhost-user-blk.c | 19 ++-
hw/virtio/vhost.c | 39 ++++-
include/hw/virtio/vhost-user-blk.h | 10 ++
tests/qtest/libqos/virtio-blk.c | 14 +-
tests/qtest/vhost-user-test.c | 290 +++++++++++++++++++++++++++++++------
5 files changed, 322 insertions(+), 50 deletions(-)
--
2.7.4
