Skip to content
  • Dima Stepanov's avatar
    f5b22d06
    vhost: recheck dev state in the vhost_migration_log routine · f5b22d06
    Dima Stepanov authored
    vhost-user devices can get a disconnect in the middle of the VHOST-USER
    handshake on the migration start. If disconnect event happened right
    before sending next VHOST-USER command, then the vhost_dev_set_log()
    call in the vhost_migration_log() function will return error. This error
    will lead to the assert() and close the QEMU migration source process.
    For the vhost-user devices the disconnect event 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
    Update the vhost-user-blk device with the internal started_vu field which
    will be used for initialization (vhost_user_blk_start) and clean up
    (vhost_user_blk_stop). This additional flag in the VhostUserBlk structure
    will be used to track whether the device really needs to be stopped and
    cleaned up on a vhost-user level.
    The disconnect event will set the overall VHOST device (not vhost-user) to
    the stopped state, so it can be used by the general vhost_migration_log
    routine.
    Such approach could be propogated to the other vhost-user devices, but
    better idea is just to make the same connect/disconnect code for all the
    vhost-user devices.
    
    This migration issue was slightly discussed earlier:
      - https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg01509.html
      - https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05241.html
    
    
    
    Signed-off-by: default avatarDima Stepanov <dimastep@yandex-team.ru>
    Reviewed-by: default avatarRaphael Norwitz <raphael.norwitz@nutanix.com>
    Message-Id: <9fbfba06791a87813fcee3e2315f0b904cc6789a.1599813294.git.dimastep@yandex-team.ru>
    Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    f5b22d06
    vhost: recheck dev state in the vhost_migration_log routine
    Dima Stepanov authored
    vhost-user devices can get a disconnect in the middle of the VHOST-USER
    handshake on the migration start. If disconnect event happened right
    before sending next VHOST-USER command, then the vhost_dev_set_log()
    call in the vhost_migration_log() function will return error. This error
    will lead to the assert() and close the QEMU migration source process.
    For the vhost-user devices the disconnect event 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
    Update the vhost-user-blk device with the internal started_vu field which
    will be used for initialization (vhost_user_blk_start) and clean up
    (vhost_user_blk_stop). This additional flag in the VhostUserBlk structure
    will be used to track whether the device really needs to be stopped and
    cleaned up on a vhost-user level.
    The disconnect event will set the overall VHOST device (not vhost-user) to
    the stopped state, so it can be used by the general vhost_migration_log
    routine.
    Such approach could be propogated to the other vhost-user devices, but
    better idea is just to make the same connect/disconnect code for all the
    vhost-user devices.
    
    This migration issue was slightly discussed earlier:
      - https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg01509.html
      - https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05241.html
    
    
    
    Signed-off-by: default avatarDima Stepanov <dimastep@yandex-team.ru>
    Reviewed-by: default avatarRaphael Norwitz <raphael.norwitz@nutanix.com>
    Message-Id: <9fbfba06791a87813fcee3e2315f0b904cc6789a.1599813294.git.dimastep@yandex-team.ru>
    Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
Loading