1. 30 7月, 2013 1 次提交
  2. 26 4月, 2013 1 次提交
    • L
      qemu: detect vfio-pci device and its bootindex parameter · 5b90ef08
      Laine Stump 提交于
      QEMU_CAPS_DEVICE_VFIO_PCI is set if the device named "vfio-pci" is
      supported in the qemu binary.
      
      QEMU_CAPS_VFIO_PCI_BOOTINDEX is set if the vfio-pci device supports
      the "bootindex" parameter;  for some reason, the bootindex parameter
      wasn't included in early versions of vfio support (qemu 1.4) so we
      have to check for it separately from vfio itself.
      5b90ef08
  3. 25 4月, 2013 2 次提交
  4. 18 4月, 2013 1 次提交
  5. 16 4月, 2013 2 次提交
  6. 13 4月, 2013 2 次提交
  7. 12 4月, 2013 1 次提交
    • L
      Add USB option capability · a6e37aed
      Li Zhang 提交于
      To avoid the collision for creating USB controllers in machine->init()
      and -device xx command line, it needs to set usb=off to avoid one USB
      controller created in machine->init(). So that libvirt can use -device
      or -usb to create USB controller sucessfully.
      So QEMU_CAPS_MACHINE_USB_OPT capability is added, and it is for QEMU
      v1.3.0 onwards which supports USB option.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      a6e37aed
  8. 05 4月, 2013 3 次提交
    • P
      virCaps: get rid of defaultConsoleTargetType callback · 482e5f15
      Peter Krempa 提交于
      This patch refactors various places to allow removing of the
      defaultConsoleTargetType callback from the virCaps structure.
      
      A new console character device target type is introduced -
      VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE - to mark that no type was
      specified in the XML. This type is at the end converted to the standard
      VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL. Other types that are
      different from this default have to be processed separately in the
      device post parse callback.
      482e5f15
    • P
      virCaps: get rid of macPrefix field · 46becc18
      Peter Krempa 提交于
      Use the virDomainXMLConf structure to hold this data and tweak the code
      to avoid semantic change.
      
      Without configuration the KVM mac prefix is used by default. I chose it
      as it's in the privately administered segment so it should be usable for
      any purposes.
      46becc18
    • P
      virCaps: get rid of emulatorRequired · b5def001
      Peter Krempa 提交于
      This patch removes the emulatorRequired field and associated
      infrastructure from the virCaps object. Instead the driver specific
      callbacks are used as this field isn't enforced by all drivers.
      
      This patch implements the appropriate callbacks in the qemu and lxc
      driver and moves to check to that location.
      b5def001
  9. 02 4月, 2013 2 次提交
    • L
      Optimize machine option to set more options with it · f84b92ea
      Li Zhang 提交于
      Currently, -machine option is used only when dump-guest-core is set.
      
      To use options defined in machine option for newer version of QEMU,
      it needs to use -machine xxx, and to be compatible with older version
      -M, this patch adds QEMU_CAPS_MACHINE_OPT capability for newer
      version which supports -machine option.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      f84b92ea
    • J
      qemu: Allow migration over IPv6 · f03dcc5d
      Ján Tomko 提交于
      Allow migration over IPv6 by listening on [::] instead of 0.0.0.0
      when QEMU supports it (QEMU_CAPS_IPV6_MIGRATION) and there is
      at least one v6 address configured on the system.
      
      Use virURIParse in qemuMigrationPrepareDirect to allow parsing
      IPv6 addresses, which would cause an 'incorrect :port' error
      message before.
      
      Move setting of migrateFrom from qemuMigrationPrepare{Direct,Tunnel}
      after domain XML parsing, since we need the QEMU binary path from it
      to get its capabilities.
      
      Bug: https://bugzilla.redhat.com/show_bug.cgi?id=846013
      f03dcc5d
  10. 25 3月, 2013 1 次提交
    • E
      Revert "qemu: detect multi-head qxl via more than version check" · 7524cd89
      Eric Blake 提交于
      This reverts commit 5ac846e4.
      
      After further discussions with Alon Levy, I learned the following:
      
      The use of '-vga qxl' vs. '-device qxl-vga' is completely orthogonal
      to whether ram_size can be exposed.  Downstream distros are interested
      in backporting support for multi-head qxl, but this can be done in
      one of two ways:
      1. Support one head per PCI device.  If you do this, then it makes
      sense to have full control over the PCI address of each device. For
      full control, you need '-device qxl-vga' instead of '-vga qxl'.
      2. Support multiple heads through a single PCI device.  If you do
      this, then you need to allocate more RAM to that PCI device (enough
      ram to cover the multiple screens).  Here, the device is hard-coded
      to 0:0:2.0, both in qemu and libvirt code.
      
      Apparently, backporting ram_size changes to allow multiple heads in
      a single device is much easier than backporting multiple device
      support.  Furthermore, the presence or absence of qxl-vga.surfaces
      is no different than the presence or absence of qxl-vga.ram_size;
      both properties can be applied regardless of whether you have one
      PCI device (-vga qxl) or multiple (-device qxl-vga), so this property
      is NOT a good witness of whether '-device qxl-vga' support has been
      backported.
      
      Downstream RHEL will NOT be using this patch; and worse, leaving this
      patch in risks doing the wrong thing if compiling upstream libvirt
      on RHEL, so the best course of action is to revert it.  That means
      that libvirt will go back to only using '-device qxl-vga' for qemu
      >= 1.2, but this is just fine because we know of no distros that plan
      on backporting multiple PCI address support to any older version of
      qemu.  Meanwhile, downstream can still use ram_size to pack multiple
      heads through a single PCI device.
      7524cd89
  11. 22 3月, 2013 1 次提交
  12. 20 3月, 2013 1 次提交
    • O
      qemu: add dtb option support · 0b3509e2
      Olivia Yin 提交于
      The "dtb" option sets the filename for the device tree.
      If without this option support, "-dtb file" will be converted into
      <qemu:commandline> in domain XML file.
      For example, '-dtb /media/ram/test.dtb' will be converted into
        <qemu:commandline>
          <qemu:arg value='-dtb'/>
          <qemu:arg value='/media/ram/test.dtb'/>
        </qemu:commandline>
      
      This is not very friendly.
      This patchset add special <dtb> tag like <kernel> and <initrd>
      which is easier for user to write domain XML file.
        <os>
          <type arch='ppc' machine='ppce500v2'>hvm</type>
          <kernel>/media/ram/uImage</kernel>
          <initrd>/media/ram/ramdisk</initrd>
          <dtb>/media/ram/test.dtb</dtb>
          <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline>
        </os>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      0b3509e2
  13. 15 3月, 2013 2 次提交
  14. 14 3月, 2013 2 次提交
    • E
      qemu: detect multi-head qxl via more than version check · 5ac846e4
      Eric Blake 提交于
      Multi-head QXL support is so useful that distros have started to
      backport it to qemu earlier than 1.2.  After discussion with
      Alon Levy, we determined that the existence of the qxl-vga.surfaces
      property is a reliable indicator of whether '-device qxl-vga' works,
      or whether we have to stick to the older '-vga qxl'.  I'm leaving
      in the existing check for QEMU_CAPS_DEVICE_VIDEO_PRIMARY tied to
      qemu 1.2 and newer (in case qemu is built without qxl support),
      but for those distros that backport qxl, this additional capability
      check will allow the correct command line for both RHEL 6.3 (which
      lacks the feature) and RHEL 6.4 (where qemu still claims to be
      version 0.12.2.x, but has backported multi-head qxl).
      
      * src/qemu/qemu_capabilities.c (virQEMUCapsObjectPropsQxlVga): New
      property test.
      (virQEMUCapsExtractDeviceStr): Probe for backport of new
      capability to qemu earlier than 1.2.
      * tests/qemuhelpdata/qemu-kvm-1.2.0-device: Update test.
      * tests/qemuhelpdata/qemu-1.2.0-device: Likewise.
      * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device:
      Likewise.
      5ac846e4
    • V
      S390: QEMU driver support for CCW addresses · 608512b2
      Viktor Mihajlovski 提交于
      This commit adds the QEMU driver support for CCW addresses. The
      current QEMU only allows virtio devices to be attached to the
      CCW bus. We named the new capability indicating that support
      QEMU_CAPS_VIRTIO_CCW accordingly.
      
      The fact that CCW devices can only be assigned to domains with a
      machine type of s390-ccw-virtio requires a few extra checks for
      machine type in qemu_command.c on top of querying
      QEMU_CAPS_VIRTIO_{CCW|S390}.
      
      The majority of the new functions deals with CCW address generation
      and management.
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      608512b2
  15. 25 2月, 2013 2 次提交
    • P
      qemu: Implement support for EGD backend for virtio-rng · 820019fc
      Peter Krempa 提交于
      This patch adds a new capability bit QEMU_CAPS_OBJECT_RNG_EGD and code
      to support the egd backend for the VirtIO RNG device.
      
      The device is added by 3 qemu command line options:
      -chardev socket,id=charrng0,host=1.2.3.4,port=1234 (communication
                                                          backend)
      -object rng-egd,chardev=charrng0,id=rng0 (RNG protocol client)
      -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (the RNG device)
      820019fc
    • P
      qemu: Implement support for default 'random' backend for virtio-rng · 234a5560
      Peter Krempa 提交于
      This patch implements support for the virtio-rng-pci device and the
      rng-random backend in qemu.
      
      Two capabilities bits are added to track support for those:
      
      QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and
      QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support.
      
      qemu is invoked with these additional parameters if the device is
      enabled:
      
      -object rng-random,id=rng0,filename=/test/phile (to add the backend)
      -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)
      234a5560
  16. 23 2月, 2013 1 次提交
  17. 19 2月, 2013 1 次提交
    • D
      Add capabilities bit for -no-kvm-pit-reinjection · 41046256
      Doug Goldstein 提交于
      The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
      newer to set the lost tick policy for the PIT. While the
      -no-kvm-pit-reinjection option is depreacated, it is still supported at
      least through 1.4, it is better to not lose the functionality.
      41046256
  18. 14 2月, 2013 1 次提交
  19. 08 2月, 2013 2 次提交
  20. 01 2月, 2013 1 次提交
  21. 25 1月, 2013 2 次提交
    • D
      Fix bogus reporting of KVM support for non-native emulators · c29eafc8
      Daniel P. Berrange 提交于
      A logic bug meant we reported KVM was possible for every
      architecture, merely based on whether the query-kvm command
      exists. We should instead have been doing it based on whether
      the query-kvm command returns 'present: 1'
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      c29eafc8
    • D
      Fix performance & reliabilty of QMP probing · 1b253a10
      Daniel P. Berrange 提交于
      This previous commit
      
        commit 1a50ba2c
        Author: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
        Date:   Mon Nov 26 15:17:13 2012 +0100
      
          qemu: Fix QMP Capabability Probing Failure
      
      which attempted to make sure the QEMU process used for probing
      ran as the right user id, caused serious performance regression
      and unreliability in probing. The -daemonize switch in QEMU
      guarantees that the monitor socket is present before the parent
      process exits. This means libvirtd is guaranteed to be able to
      connect immediately. By switching from -daemonize to the
      virCommandDaemonize API libvirtd was no longer synchronized with
      QEMU's startup process. The result was that the QEMU monitor
      failed to open and went into its 200ms sleep loop. This happened
      for all 25 binaries resulting in 5 seconds worth of sleeping
      at libvirtd startup. In addition sometimes when libvirt connected,
      QEMU would be partially initialized and crash causing total
      failure to probe that binary.
      
      This commit reverts the previous change, ensuring we do use the
      -daemonize flag to QEMU. Startup delay is cut from 7 seconds
      to 2 seconds on my machine, which is on a par with what it was
      prior to the capabilities rewrite.
      
      To deal with the fact that QEMU needs to be able to create the
      pidfile, we switch pidfile location fron runDir to libDir, which
      QEMU is guaranteed to be able to write to.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      1b253a10
  22. 17 1月, 2013 1 次提交
    • J
      qemu: fix QEMU_CAPS_NO_ACPI detection · 31494974
      Ján Tomko 提交于
      In commit c4bbaaf8, caps->arch was checked uninitialized, rendering the
      whole check useless.
      
      This patch moves the conditional setting of QEMU_CAPS_NO_ACPI to
      qemuCapsInitQMP, and removes the no longer needed exception for S390.
      
      It also clears the flag for all non-x86 archs instead of just S390 in
      qemuCapsInitHelp.
      31494974
  23. 16 1月, 2013 2 次提交
  24. 12 1月, 2013 1 次提交
  25. 11 1月, 2013 2 次提交
  26. 10 1月, 2013 2 次提交