1. 21 8月, 2018 3 次提交
  2. 14 8月, 2018 1 次提交
  3. 09 8月, 2018 2 次提交
  4. 08 8月, 2018 1 次提交
  5. 07 8月, 2018 1 次提交
  6. 30 7月, 2018 1 次提交
  7. 27 7月, 2018 1 次提交
  8. 20 7月, 2018 3 次提交
  9. 19 7月, 2018 3 次提交
    • E
      conf: Introduce new video type 'none' · d48813e8
      Erik Skultety 提交于
      Historically, we've always enabled an emulated video device every time we
      see that graphics should be supported with a guest. With the appearance
      of mediated devices which can support QEMU's vfio-display capability,
      users might want to use such a device as the only video device.
      Therefore introduce a new, effectively a 'disable', type for video
      device.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d48813e8
    • E
      conf: Introduce new <hostdev> attribute 'display' · d54e45b6
      Erik Skultety 提交于
      QEMU 2.12 introduced a new type of display for mediated devices using
      vfio-pci backend which allows a mediated device to be used as a VGA
      compatible device as an alternative to an emulated video device. QEMU
      exposes this feature via a vfio device property 'display' with supported
      values 'on/off/auto' (libvirt will default to 'off').
      
      This patch adds the necessary bits to domain config handling in order to
      expose this feature. Since there's no convenient way for libvirt to come
      up with usable defaults for the display setting, simply because libvirt
      is not able to figure out which of the display implementations - dma-buf
      which requires OpenGL support vs vfio regions which doesn't need OpenGL
      (works with OpenGL enabled too) - the underlying mdev uses.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d54e45b6
    • E
      qemu: Introduce a new graphics display type 'headless' · d8266ebe
      Erik Skultety 提交于
      Since 2.10 QEMU supports a new display type egl-headless which uses the
      drm nodes for OpenGL rendering copying back the rendered bits back to
      QEMU into a dma-buf which can be accessed by standard "display" apps
      like VNC or SPICE. Although this display type can be used on its own,
      for any practical use case it makes sense to pair it with either VNC or
      SPICE display. The clear benefit of this display is that VNC gains
      OpenGL support, which it natively doesn't have, and SPICE gains remote
      OpenGL support (native OpenGL support only works locally through a UNIX
      socket, i.e. listen type=socket/none).
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d8266ebe
  10. 10 7月, 2018 5 次提交
  11. 04 7月, 2018 1 次提交
  12. 03 7月, 2018 5 次提交
  13. 02 7月, 2018 1 次提交
    • J
      qemu_migration: Check for active domain after talking to remote daemon · 5f998219
      Jiri Denemark 提交于
      Once we called qemuDomainObjEnterRemote to talk to the destination
      daemon during a peer to peer migration, the vm lock is released and we
      only hold an async job. If the source domain dies at this point the
      monitor EOF callback is allowed to do its job and (among other things)
      clear all private data irrelevant for stopped domain. Thus when we call
      qemuDomainObjExitRemote, the domain may already be gone and we should
      avoid touching runtime private data (such as current job info).
      
      In other words after acquiring the lock in qemuDomainObjExitRemote, we
      need to check the domain is still alive. Unless we're doing offline
      migration.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1589730Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      5f998219
  14. 28 6月, 2018 2 次提交
  15. 27 6月, 2018 1 次提交
  16. 26 6月, 2018 2 次提交
  17. 25 6月, 2018 1 次提交
  18. 21 6月, 2018 1 次提交
  19. 20 6月, 2018 2 次提交
  20. 19 6月, 2018 3 次提交