1. 12 10月, 2016 2 次提交
    • P
      qemu_capabilities: mark QEMU_CAPS_VGA_QXL capability as deprecated · 05af6784
      Pavel Hrdina 提交于
      If QEMU in question supports QMP, this capability is set if
      QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
      libvirt needs to parse *help*, because there is no QMP support, it
      checks for existence of "-vga qxl", but it also parses output of
      "-device ?" and sets QEMU_CAPS_DEVICE_QXL too.
      
      Now that libvirt supports only QEMU that has "-device" implemented it's
      safe to drop this capability and stop using it.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      05af6784
    • P
      qemu_capabilities: join capabilities for qxl and qxl-vga devices · 34a4447b
      Pavel Hrdina 提交于
      This patch simplifies QEMU capabilities for QXL video device.  QEMU
      exposes this device as *qxl-vga* and *qxl* and they are both the same
      device with the same set of parameters, the only difference is that
      *qxl-vga* includes VGA compatibility.
      
      Based on QEMU code they are tied together so it's safe to check only for
      presence of only one of them.
      
      This patch also removes an invalid test case "video-qxl-sec-nodevice"
      where there is only *qxl-vga* device and *qxl* device is not present.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      34a4447b
  2. 07 10月, 2016 1 次提交
    • D
      qemu: fix command line building for iommu devices · 5dee6686
      Daniel P. Berrange 提交于
      The intel-iommu device has existed since QEMU 2.2.0, but
      it was only possible to create it with -device since
      QEMU 2.7.0, thanks to:
      
        commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
        Author: Marcel Apfelbaum <marcel@redhat.com>
        Date:   Mon Jun 27 18:38:34 2016 +0300
      
          hw/iommu: enable iommu with -device
      
          Use the standard '-device intel-iommu' to create the IOMMU device.
          The legacy '-machine,iommu=on' can still be used.
      
      The libvirt capability check & command line formatting code
      is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.
      
      This fixes it to use iommu=on instead.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      5dee6686
  3. 18 8月, 2016 1 次提交
    • J
      Introduce QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY · 41f5c2ca
      Ján Tomko 提交于
      Check whether the disable-legacy property is present on the following
      devices:
        virtio-balloon-pci
        virtio-blk-pci
        virtio-scsi-pci
        virtio-serial-pci
        virtio-9p-pci
        virtio-net-pci
        virtio-rng-pci
        virtio-gpu-pci
        virtio-input-host-pci
        virtio-keyboard-pci
        virtio-mouse-pci
        virtio-tablet-pci
      
      Assuming that if QEMU knows other virtio devices where this property
      is applicable, it will have at least one of these devices.
      
      Added in QEMU by:
      commit e266d421490e0ae83044bbebb209b2d3650c0ba6
          virtio-pci: add flags to enable/disable legacy/modern
      41f5c2ca
  4. 04 8月, 2016 1 次提交
    • M
      Introduce SMM feature · d0e4be9d
      Michal Privoznik 提交于
      Since its release of 2.4.0 qemu is able to enable System
      Management Module in the firmware, or disable it. We should
      expose this capability in the XML. Unfortunately, there's no good
      way to determine whether the binary we are talking to supports
      it. I mean, if qemu's run with real machine type, the smm
      attribute can be seen in 'qom-list /machine' output. But it's not
      there when qemu's run with -M none. Therefore we're stuck with
      version based check.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      d0e4be9d
  5. 12 7月, 2016 1 次提交
  6. 07 7月, 2016 2 次提交
    • P
      qemu: caps: Always assume QEMU_CAPS_SMP_TOPOLOGY · e114b091
      Peter Krempa 提交于
      Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50
      prior to 0.12.0, our minimum supported qemu version.
      
      $ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62
      v0.11.0-rc0-449-gdc6b1c0
      $ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab
      v0.12.0-rc0~1477
      e114b091
    • P
      qemu: detect -display · ca57b5d6
      Paolo Bonzini 提交于
      Add a new capability for the -display command line option, which has
      been present since QEMU 1.0.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      ca57b5d6
  7. 14 6月, 2016 2 次提交
  8. 09 6月, 2016 1 次提交
  9. 07 6月, 2016 1 次提交
  10. 24 5月, 2016 1 次提交
  11. 23 5月, 2016 2 次提交
  12. 17 5月, 2016 3 次提交
    • A
      qemu: Drop QEMU_CAPS_VIRTIO_BLK_SG_IO · 0e8a72a5
      Andrea Bolognani 提交于
      The only QEMU versions that don't have such capability are <0.11,
      which we no longer support anyway
      0e8a72a5
    • A
      qemu: Drop QEMU_CAPS_CPU_HOST · 859743c2
      Andrea Bolognani 提交于
      The only QEMU versions that don't have such capability are <0.11,
      which we no longer support anyway
      859743c2
    • A
      qemu: Drop QEMU_CAPS_PCI_ROMBAR · 8531b85b
      Andrea Bolognani 提交于
      The only QEMU versions that don't have such capability are <0.12,
      which we no longer support anyway.
      
      Additionally, this solves the issue of some QEMU binaries being
      reported as not having such capability just because they lacked
      the {kvm-}pci-assign QMP object.
      8531b85b
  13. 16 5月, 2016 2 次提交
  14. 06 5月, 2016 5 次提交
  15. 04 5月, 2016 1 次提交
    • J
      qemu: Add capability for virtio-scsi iothreads · e2faa976
      John Ferlan 提交于
      An iothread for virtio-scsi is a property of the controller. Add a lookup
      of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse
      the output.  For both, support for the iothread was added in qemu 2.4
      while support for virtio-scsi in general was added in qemu 1.4.
      
      Modify the various mock capabilities replies (by hand) to reflect the
      when virtio-scsi was supported and then specifically when the iothread
      property was added. For versions prior to 1.4, use the no device error
      return for virtio-scsi. For versions 1.4 to before 2.4, add some data
      for virtio-scsi-pci even though it isn't complete we're not looking for
      anything specific there anyway. For 2.4 to 2.6, add a more complete reply.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      e2faa976
  16. 03 5月, 2016 1 次提交
  17. 02 5月, 2016 1 次提交
  18. 15 4月, 2016 2 次提交
  19. 11 3月, 2016 1 次提交
  20. 01 3月, 2016 1 次提交
  21. 12 1月, 2016 2 次提交
  22. 11 1月, 2016 1 次提交
  23. 30 11月, 2015 2 次提交
  24. 27 11月, 2015 2 次提交
  25. 19 11月, 2015 1 次提交
    • J
      qemu: Use -incoming defer for migrations · 2c4ba8b4
      Jiri Denemark 提交于
      Traditionally, we pass incoming migration URI on QEMU command line,
      which has some drawbacks. Depending on the URI QEMU may initialize its
      migration state immediately without giving us a chance to set any
      additional migration parameters (this applies mainly for fd: URIs). For
      some URIs the monitor may be completely blocked from the beginning until
      migration is finished, which means we may be stuck in qmp_capabilities
      command without being able to send any QMP commands.
      
      QEMU solved this by introducing "defer" parameter for -incoming command
      line option. This will tell QEMU to prepare for an incoming migration
      while the actual incoming URI is sent using migrate-incoming QMP
      command. Before calling this command we can normally talk to the
      monitor and even set any migration parameters which will be honored by
      the incoming migration.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      2c4ba8b4