1. 12 1月, 2016 3 次提交
    • L
      qemu: auto-add a USB2 controller set for Q35 machines · bd04ad42
      Laine Stump 提交于
      Use virDomainDefAddUSBController() to add an EHCI1+UHCI1+UHCI2+UHCI3
      controller set to newly defined Q35 domains that don't have any USB
      controllers defined.
      bd04ad42
    • L
      qemu: prefer 00:1D.x and 00:1A.x for USB2 controllers on Q35 · 163338ec
      Laine Stump 提交于
      The real Q35 machine puts the first USB controller set (EHCI+(UHCIx4))
      on bus 0 slot 0x1D, and the 2nd USB controller set on bus 0 slot 0x1A,
      so let's attempt to make the virtual machine match that for
      controllers with auto-assigned addresses when possible.
      
      Three test cases were added to assure that the proper addresses are
      assigned - one with a single set of unaddressed USB controllers, one
      with 3 (to grab both preferred slots plus one more), and one with the
      order of the controller definitions reordered, to assure that the
      auto-assignment isn't mixed up by order.
      163338ec
    • M
      qemu: Introduce QEMU_CAPS_VSERPORT_CHANGE · 0a84286d
      Michal Privoznik 提交于
      This capability tells if qemu is capable of vserport_change
      events.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      0a84286d
  2. 11 1月, 2016 3 次提交
  3. 10 1月, 2016 2 次提交
  4. 09 1月, 2016 11 次提交
  5. 08 1月, 2016 4 次提交
  6. 07 1月, 2016 1 次提交
  7. 05 1月, 2016 1 次提交
    • M
      qemu: Specify format= iff disk source is not empty · d7db33bf
      Michal Privoznik 提交于
      Just recently, qemu forbade specifying format for sourceless
      disks (qemu commit 39c4ae941ed992a3bb5). It kind of makes sense.
      If there's no file to open, why specify its format. Anyway, I
      have a domain like this:
      
          <disk type='file' device='cdrom'>
            <driver name='qemu' type='raw'/>
            <target dev='hda' bus='ide'/>
            <readonly/>
            <address type='drive' controller='0' bus='0' target='0' unit='0'/>
          </disk>
      
      and obviously I am unable to start it. Therefore, a fix on our
      side is needed too.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      d7db33bf
  8. 29 12月, 2015 1 次提交
  9. 24 12月, 2015 2 次提交
  10. 21 12月, 2015 2 次提交
    • A
      pci: Introduce virPCIStubDriver enumeration · 6d9cdd2a
      Andrea Bolognani 提交于
      This replaces the virPCIKnownStubs string array that was used
      internally for stub driver validation.
      
      Advantages:
      
        * possible values are well-defined
        * typos in driver names will be detected at compile time
        * avoids having several copies of the same string around
        * no error checking required when setting / getting value
      
      The names used mirror those in the
      virDomainHostdevSubsysPCIBackendType enumeration.
      6d9cdd2a
    • A
      pci: Remove 'reprobe' parameter from virPCIDeviceUnbind() · e1b24583
      Andrea Bolognani 提交于
      The value is not inspected inside the function, so it makes more
      sense for the caller to change the device's setting explicitly.
      e1b24583
  11. 19 12月, 2015 1 次提交
    • J
      Xen: support maxvcpus in xm and xl config · 5b74103b
      Jim Fehlig 提交于
      From: Ian Campbell <ian.campbell@citrix.com>
      
      xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
      as a bit map of which cpus are online (default is all).
      
      xend from 4.0 onwards understands maxvcpus as maxvcpus and
      vcpus as the number which are online (from 0..N-1). The
      upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
      claims that if maxvcpus is omitted then the old behaviour
      (i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
      in this case vcpu==maxcpus==online cpus. This is good for us
      because handling anything else would be fiddly.
      
      This patch changes parsing of the virDomainDef maxvcpus and vcpus
      entries to use the corresponding 'maxvcpus' and 'vcpus' settings
      from xm and xl config. It also drops use of the old Xen 3.x
      'vcpu_avail' setting.
      
      The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
      maxvcpus is simply a count, not a bit mask), which is particularly
      crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
      expected to support vcpu placement, and therefore only the boot
      vcpu's info lives in the shared info page).
      
      Existing tests adjusted accordingly, and new tests added for the
      'maxvcpus' setting.
      5b74103b
  12. 18 12月, 2015 9 次提交