1. 02 12月, 2017 2 次提交
  2. 16 11月, 2017 1 次提交
    • L
      fix: unrealize virtio device if we fail to hotplug it · 7abea552
      linzhecheng 提交于
      If we fail to hotplug virtio-blk device and then suspend
      or shutdown VM, qemu is likely to crash.
      
      Re-production steps:
      1. Run VM named vm001
      2. Create a virtio-blk.xml which contains wrong configurations:
      <disk device="lun" rawio="yes" type="block">
        <driver cache="none" io="native" name="qemu" type="raw" />
        <source dev="/dev/mapper/11-dm" />
        <target bus="virtio" dev="vdx" />
      </disk>
      3. Run command : virsh attach-device vm001 virtio-blk.xml
      error: Failed to attach device from blk-scsi.xml
      error: internal error: unable to execute QEMU command 'device_add': Please set scsi=off for virtio-blk devices in order to use virtio 1.0
      it means hotplug virtio-blk device failed.
      4. Suspend or shutdown VM will leads to qemu crash
      
      Problem happens in virtio_vmstate_change which is called by
      vm_state_notify:
      vdev’s parent_bus is NULL, so qdev_get_parent_bus(DEVICE(vdev)) will crash.
      virtio_vmstate_change is added to the list vm_change_state_head at virtio_blk_device_realize(virtio_init),
      but after hotplug virtio-blk failed, virtio_vmstate_change will not be removed from vm_change_state_head.
      Adding unrealize function of virtio-blk device can solve this problem.
      Signed-off-by: Nlinzhecheng <linzhecheng@huawei.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      7abea552
  3. 15 10月, 2017 1 次提交
  4. 27 9月, 2017 1 次提交
  5. 19 9月, 2017 1 次提交
    • E
      osdep.h: Prohibit disabling assert() in supported builds · 262a69f4
      Eric Blake 提交于
      We already have several files that knowingly require assert()
      to work, sometimes because refactoring the code for proper
      error handling has not been tackled yet; there are probably
      other files that have a similar situation but with no comments
      documenting the same.  In fact, we have places in migration
      that handle untrusted input with assertions, where disabling
      the assertions risks a worse security hole than the current
      behavior of losing the guest to SIGABRT when migration fails
      because of the assertion.  Promote our current per-file
      safety-valve to instead be project-wide, and expand it to also
      cover glib's g_assert().
      
      Note that we do NOT want to encourage 'assert(side-effects);'
      (that is a bad practice that prevents copy-and-paste of code to
      other projects that CAN disable assertions; plus it costs
      unnecessary reviewer mental cycles to remember whether a project
      special-cases the crippling of asserts); and we would LIKE to
      fix migration to not rely on asserts (but that takes a big code
      audit).  But in the meantime, we DO want to send a message
      that anyone that disables assertions has to tweak code in order
      to compile, making it obvious that they are taking on additional
      risk that we are not going to support.  At the same time, leave
      comments mentioning NDEBUG in files that we know still need to
      be scrubbed, so there is at least something to grep for.
      
      It would be possible to come up with some other mechanism for
      doing runtime checking by default, but which does not abort
      the program on failure, while leaving side effects in place
      (unlike how crippling assert() avoids even the side effects),
      perhaps under the name q_verify(); but it was not deemed worth
      the effort (developers should not have to learn a replacement
      when the standard C macro works just fine, and it would be a lot
      of churn for little gain).  The patch specifically uses #error
      rather than #warn so that a user is forced to tweak the header
      to acknowledge the issue, even when not using a -Werror
      compilation.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Reviewed-by: NThomas Huth <thuth@redhat.com>
      
      Message-Id: <20170911211320.25385-1-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      262a69f4
  6. 02 6月, 2017 1 次提交
  7. 19 5月, 2017 1 次提交
  8. 18 5月, 2017 1 次提交
    • G
      virtio: allow broken device to notify guest · 66453cff
      Greg Kurz 提交于
      According to section 2.1.2 of the virtio-1 specification:
      
      "The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that
      a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET,
      the device MUST send a device configuration change notification to the
      driver."
      
      Commit "f5ed3663 virtio: stop virtqueue processing if device is broken"
      introduced a virtio_error() call that just does that:
      
      - internally mark the device as broken
      - set the DEVICE_NEEDS_RESET bit in the status
      - send a configuration change notification
      
      Unfortunately, virtio_notify_vector(), called by virtio_notify_config(),
      returns right away when the device is marked as broken and the notification
      isn't sent in this case.
      
      The spec doesn't say whether a broken device can send notifications
      in other situations or not. But since the driver isn't supposed to do
      anything but to reset the device, it makes sense to keep the check in
      virtio_notify_config().
      
      Marking the device as broken AFTER the configuration change notification was
      sent is enough to fix the issue.
      Signed-off-by: NGreg Kurz <groug@kaod.org>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      66453cff
  9. 22 3月, 2017 1 次提交
  10. 16 3月, 2017 3 次提交
  11. 02 3月, 2017 4 次提交
  12. 18 2月, 2017 8 次提交
  13. 01 2月, 2017 1 次提交
  14. 25 1月, 2017 1 次提交
  15. 20 1月, 2017 2 次提交
  16. 19 1月, 2017 2 次提交
  17. 17 1月, 2017 1 次提交
  18. 10 1月, 2017 4 次提交
  19. 04 1月, 2017 4 次提交