1. 22 9月, 2015 1 次提交
  2. 15 9月, 2015 1 次提交
  3. 12 9月, 2015 1 次提交
    • C
      qemu: command: Report stderr from qemu-bridge-helper · db35beaa
      Cole Robinson 提交于
      There's a couple reports of things failing in this area (bug 1259070),
      but it's tough to tell what's going wrong without stderr from
      qemu-bridge-helper. So let's report stderr in the error message
      
      Couple new examples:
      
      virbr0 is inactive:
      internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
      stderr=failed to get mtu of bridge `virbr0': No such device
      
      bridge isn't on the ACL:
      internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=br0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
      stderr=access denied by acl file
      db35beaa
  4. 04 9月, 2015 2 次提交
    • J
      qemu: Need to check for machine.os when using ADDRESS_TYPE_CCW · a39ab909
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1258361
      
      When attaching a disk, controller, or rng using an address type ccw
      or s390, we need to ensure the support is provided by both the machine.os
      and the emulator capabilities (corollary to unconditional setting when
      address was not provided for the correct machine.os and emulator.
      
      For an inactive guest, an addition followed by a start would cause the
      startup to fail after qemu_command builds the command line and attempts
      to start the guest. For an active guest, libvirtd would crash.
      a39ab909
    • J
      qemu: Introduce qemuDomainMachineIsS390CCW · d334c917
      John Ferlan 提交于
      Rather than have different usages of STR function in order to determine
      whether the domain is s390-ccw or s390-ccw-virtio, make a single API
      which will check the machine.os prefix. Then use the function.
      d334c917
  5. 02 9月, 2015 1 次提交
    • J
      qemu: add udp interface support · 5c668a78
      Jonathan Toppins 提交于
      Adds a new interface type using UDP sockets, this seems only applicable
      to QEMU but have edited tree-wide to support the new interface type.
      
      The interface type required the addition of a "localaddr" (local
      address), this then maps into the following xml and qemu call.
      
      <interface type='udp'>
        <mac address='52:54:00:5c:67:56'/>
        <source address='127.0.0.1' port='11112'>
          <local address='127.0.0.1' port='22222'/>
        </source>
        <model type='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
      </interface>
      
      QEMU call:
      	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222
      
      Notice the xml "local" entry becomes the "localaddr" for the qemu call.
      
      reference:
      http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      5c668a78
  6. 24 8月, 2015 1 次提交
  7. 14 8月, 2015 1 次提交
    • G
      Check if qemu-bridge-helper exists and is executable · 151ba022
      Guido Günther 提交于
      Otherwise the error is just
      
          error: Failed to create domain from test1.xml
          error: failed to retrieve file descriptor for interface: Transport endpoint is not connected
      
      since we don't get a sensible error after the fork.
      151ba022
  8. 13 8月, 2015 1 次提交
    • J
      conf: Check for hostdev conflicts when assign default disk address · 1b08cc17
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1210587  (completed)
      
      When generating the default drive address for a SCSI <disk> device,
      check the generated address to ensure it doesn't conflict with a SCSI
      <hostdev> address. The <disk> address generation algorithm uses the
      <target> "dev" name in order to determine which controller and unit
      in order to place the device. Since a SCSI <hostdev> device doesn't
      require a target device name, its placement on the guest SCSI address
      "could" conflict.  For instance, if a SCSI <hostdev> exists at
      controller=0 unit=0 and an attempt to hotplug 'sda' into the guest
      made, there would be a conflict if the <hostdev> is already using
      /dev/sda.
      1b08cc17
  9. 12 8月, 2015 2 次提交
    • L
      Revert "qemu: Allow to plug virtio-net-pci into PCIe slot" · d5e6d1cf
      Laine Stump 提交于
      This reverts commit ede34470, which
      was apparently written based on testing performed before commits
      1e15be1b and 9a12b6 were pushed upstream. Once those two patches are in
      place, commit ede34470 is redundant, and can even cause
      incorrect/unexpected behavior when auto-assigning addresses for
      virtio-net devices.
      d5e6d1cf
    • L
      qemu: fix qemuDomainSupportsPCI() for ARM machines of "virt" machinetype · 9bd16ad3
      Laine Stump 提交于
      Commit e8d55172 updated the domain post-parse to automatically add
      pcie-root et al for certain ARM "virt" machinetypes, but didn't update
      the function qemuDomainSupportsPCI() which is called later on when we
      are auto-assigning PCI addresses and default settings for the PCI
      controller <model> and <target> attributes. The result was that PCI
      addresses weren't assigned, and the controllers didn't have their
      attribute default values set, leading to an error when the domain was
      started, e.g.:
      
        internal error: autogenerated dmi-to-pci-bridge options not set
      
      This patch adds the same check made in the earlier patch to
      qemuDomainSupportsPCI(), so that PCI address auto-assignment and
      target/model default values will be set.
      9bd16ad3
  10. 11 8月, 2015 1 次提交
  11. 10 8月, 2015 9 次提交
    • M
    • L
      qemu: support new pci controller model "pcie-switch-downstream-port" · 7d69387c
      Laine Stump 提交于
      This is backed by the qemu device xio3130-downstream. It can only be
      connected to a pcie-switch-upstream-port (x3130-upstream) on the
      upstream side.
      7d69387c
    • L
      conf: new pcie-controller model "pcie-switch-downstream-port" · 76379a6e
      Laine Stump 提交于
      This controller can be connected only to a port on a
      pcie-switch-upstream-port. It provides a single hotpluggable port that
      will accept any PCI or PCIe device, as well as any device requiring a
      pcie-*-port (the only current example of such a device is the
      pcie-switch-upstream-port).
      76379a6e
    • L
      qemu: support new pci controller model "pcie-switch-upstream-port" · cb99086d
      Laine Stump 提交于
      this is backed by the qemu device x3130-upstream. It can only plug
      into a pcie-root-port or pcie-switch-downstream-port.
      cb99086d
    • L
      conf: new pci controller model "pcie-switch-upstream-port" · 38ea9515
      Laine Stump 提交于
      This controller can be connected only to a pcie-root-port or a
      pcie-switch-downstream-port (which will be added in a later patch),
      which is the reason for the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
      32 ports (slot=0 to slot=31) on the downstream side, which can only
      have pci controllers of model "pcie-switch-downstream-port" plugged
      into them, which is the reason for the other new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
      38ea9515
    • L
      qemu: support new pci controller model "pcie-root-port" · 16328520
      Laine Stump 提交于
      This is backed by the qemu device ioh3420.
      
      chassis and port from the <target> subelement are used to store/set the
      respective qemu device options for the ioh3420. Currently, chassis is
      set to be the index of the controller, and port is set to
      "(slot << 3) + function" (per suggestion from Alex Williamson).
      16328520
    • L
      conf: new pci controller model "pcie-root-port" · dce3b8be
      Laine Stump 提交于
      This controller can be connected (at domain startup time only - not
      hotpluggable) only to a port on the pcie root complex ("pcie-root" in
      libvirt config), hence the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
      will accept any PCI or PCIe device.
      
      New attributes must be added to the controller <target> subelement for
      this - chassis and port are guest-visible option values that will be
      set by libvirt with values derived from the controller's index and pci
      address information.
      dce3b8be
    • L
      qemu: implement <target chassisNr='n'/> subelement/attribute of <controller> · 18c10451
      Laine Stump 提交于
      This uses the new subelement/attribute in two ways:
      
      1) If a "pci-bridge" pci controller has no chassisNr attribute, it
      will automatically be set to the controller's index as soon as the
      controller's PCI address is known (during
      qemuDomainAssignPCIAddresses()).
      
      2) when creating the commandline for a pci-bridge device, chassisNr
      will be used to set qemu's chassis_nr option (rather than the previous
      practice of hard-coding it to the controller's index).
      18c10451
    • L
      qemu: implement <model> subelement to <controller> · 572ebdbc
      Laine Stump 提交于
      This patch provides qemu support for the contents of <model> in
      <controller> for the two existing PCI controller types that need it
      (i.e. the two controller types that are backed by a device that must
      be specified on the qemu commandline):
      
      1) pci-bridge - sets <model> name attribute default as "pci-bridge"
      
      2) dmi-to-pci-bridge - sets <model> name attribute default as
         "i82801b11-bridge".
      
      These both match current hardcoded practice.
      
      The defaults are set at the end of qemuDomainAssignPCIAddresses().
      This can't be done earlier because some of the options that will be
      autogenerated need full PCI address info for the controller, and
      because qemuDomainAssignPCIAddresses() might create extra controllers
      which would need default settings added, and that hasn't yet been done
      at the time the PostParse callbacks are being run.
      qemuDomainAssignPCIAddresses() is still called prior to the XML being
      written to disk, though, so the autogenerated defaults are persistent.
      
      qemu capabilities bits aren't checked when the domain is defined, but
      rather when the commandline is actually created (so the domain can
      possibly be defined on a host that doesn't yet have support for the
      given device, or a host different from the one where it will
      eventually be run). When the commandline is being generated we compare
      the modelName to known qemu device names implementing the given type
      of controller, and check the capabilities bit for that device.
      572ebdbc
  12. 06 8月, 2015 2 次提交
  13. 04 8月, 2015 2 次提交
  14. 25 7月, 2015 1 次提交
    • L
      qemu: reorganize loop in qemuDomainAssignPCIAddresses · 07268782
      Laine Stump 提交于
      This loop occurs just after we've assured that all devices that
      require a PCI device have been assigned and all necessary PCI
      controllers have been added. It is the perfect place to add other
      potentially auto-generated PCI controller attributes that are
      dependent on the controller's PCI address (upcoming patch).
      
      There is a convenient loop through all controllers at the end of the
      function, but the patch to add new functionality will be cleaner if we
      first rearrange that loop a bit.
      
      Note that the loop originally was accessing info.addr.pci.bus prior to
      determining that the pci part of the object was valid. This isn't
      dangerous in any way, but seemed a bit ugly, so I fixed it.
      07268782
  15. 24 7月, 2015 1 次提交
  16. 20 7月, 2015 1 次提交
  17. 15 7月, 2015 2 次提交
  18. 08 7月, 2015 7 次提交
  19. 01 7月, 2015 1 次提交
  20. 30 6月, 2015 2 次提交