1. 25 9月, 2013 10 次提交
    • L
      qemu: support ich9-intel-hda audio device · b83d26f6
      Laine Stump 提交于
      This resolves one of the issues in:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=1003983
      
      This device is identical to qemu's "intel-hda" device (known as "ich6"
      in libvirt), but has a different PCI device ID (which matches the ID
      of the hda audio built into the ich9 chipset, of course). It's not
      supported in earlier versions of qemu, so it requires a capability
      bit.
      b83d26f6
    • L
      qemu: replace multiple strcmps with a switch on an enum · 8e0dab3a
      Laine Stump 提交于
      I'm not sure why this code was written to compare the strings that it
      had just retrieved from an enum->string conversion, rather than just
      look at the original enum values, but this yields the same results,
      and is much more efficient (especially as you add more devices).
      
      This is a prerequisite for patches to resolve:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=1003983
      8e0dab3a
    • L
      qemu: allow some PCI devices to be attached to PCIe slots · 07af5192
      Laine Stump 提交于
      Part of the resolution to:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=1003983
      
      Although most devices available in qemu area defined as PCI devices,
      and strictly speaking should only be attached via a PCI slot, in
      practice qemu allows them to be attached to a PCIe slot and sometimes
      this makes sense.
      
      For example, The UHCI and EHCI USB controllers are usually attached
      directly to the PCIe "root complex" (i.e. PCIe slots) on real
      hardware, so that should be possible for a Q35-based qemu virtual
      machine as well.
      
      We still want to prefer a standard PCI slot when auto-assigning
      addresses, though, and in general to disallow attaching PCI devices
      via PCIe slots.
      
      This patch makes that possible by adding a new
      QEMU_PCI_CONNECT_TYPE_EITHER_IF_CONFIG flag. Three things are done
      with this flag:
      
      1) It is set for the "pcie-root" controller
      
      2) qemuCollectPCIAddress() now has a set of nested switches that set
      this "EITHER" flag for devices that we want to allow connecting to
      pcie-root when specifically requested in the config.
      
      3) qemuDomainPCIAddressFlagsCompatible() adds this new flag to the
      "flagsMatchMask" if the address being checked came from config rather
      than being newly auto-allocated by libvirt (this knowledge is
      conveniently already available in the "fromConfig" arg).
      
      Now any device having the EITHER flag set can be connected to
      pcie-root if explicitly requested, but auto-allocated addresses for
      those devices will still be standard PCI slots instead.
      
      This patch only loosens the restrictions on devices that have been
      specifically requested, but the setup is such that it should be fairly
      easy to add new devices.
      07af5192
    • L
      qemu: eliminate redundant if clauses in qemuCollectPCIAddress · fbd9be48
      Laine Stump 提交于
      Replace them with switch cases. This will make it more efficient when
      we add exceptions for more controller types, and other device types.
      
      This is a prerequisite for patches to resolve:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=1003983
      fbd9be48
    • L
      bridge driver: don't masquerade local subnet broadcast/multicast packets · 51e184e9
      Laszlo Ersek 提交于
      Packets sent by guests on virbrN, *or* by dnsmasq on the same, to
      - 255.255.255.255/32 (netmask-independent local network broadcast
        address), or to
      - 224.0.0.0/24 (local subnetwork multicast range)
      are never forwarded, hence it is not necessary to masquerade them.
      
      In fact we must not masquerade them: translating their source addresses or
      source ports (where applicable) may confuse receivers on virbrN.
      
      One example is the DHCP client in OVMF (= UEFI firmware for virtual
      machines):
      
        http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1506/focus=2640
      
      It expects DHCP replies to arrive from remote source port 67. Even though
      dnsmasq conforms to that, the destination address (255.255.255.255) and
      the source address (eg. 192.168.122.1) in the reply allow the UDP
      masquerading rule to match, which rewrites the source port to or above
      1024. This prevents the DHCP client in OVMF from accepting the packet.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=709418Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      51e184e9
    • L
      util/viriptables: add/remove rules that short-circuit masquerading · ccca5dc3
      Laszlo Ersek 提交于
      The functions
      - iptablesAddForwardDontMasquerade(),
      - iptablesRemoveForwardDontMasquerade
      handle exceptions in the masquerading implemented in the POSTROUTING chain
      of the "nat" table. Such exceptions should be added as chronologically
      latest, logically top-most rules.
      
      The bridge driver will call these functions beginning with the next patch:
      some special destination IP addresses always refer to the local
      subnetwork, even though they don't match any practical subnetwork's
      netmask. Packets from virbrN targeting such IP addresses are never routed
      outwards, but the current rules treat them as non-virbrN-destined packets
      and masquerade them. This causes problems for some receivers on virbrN.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      ccca5dc3
    • P
      qemu: Wire up better early error reporting · ef29de14
      Peter Krempa 提交于
      The previous patches added infrastructure to report better errors from
      monitor in some cases. This patch finalizes this "feature" by enabling
      this enhanced error reporting on early phases of VM startup. In these
      phases the possibility of qemu producing a useful error message is
      really high compared to running it during the whole life cycle. After
      the start up is complete, the feature is disabled to provide the usual
      error messages so that users are not confused by possibly irrelevant
      messages that may be in the domain log.
      
      The original motivation to do this enhancement is to capture errors when
      using VFIO device passthrough, where qemu reports errors after the
      monitor is initialized and the existing error catching code couldn't
      catch this producing a unhelpful message:
      
       # virsh start test
       error: Failed to start domain test
       error: Unable to read from monitor: Connection reset by peer
      
      With this change, the message is changed to:
      
       # virsh start test
       error: Failed to start domain test
       error: internal error: early end of file from monitor: possible problem:
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: error, group 8 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get group 8
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: Device 'vfio-pci' could not be initialized
      ef29de14
    • P
      qemu: monitor: Produce better errors on monitor hangup · 90139a62
      Peter Krempa 提交于
      Change the monitor error code to add the ability to access the qemu log
      file using a file descriptor so that we can dig in it for a more useful
      error message. The error is now logged on monitor hangups and overwrites
      a possible lesser error. A hangup on the monitor usualy means that qemu
      has crashed and there's a significant chance it produced a useful error
      message.
      
      The functionality will be latent until the next patch.
      90139a62
    • P
      qemu: monitor: Add infrastructure to access VM logs for better err msgs · 8519e9ec
      Peter Krempa 提交于
      Early VM startup errors usually produce a better error message in the
      machine log file. Currently we were accessing it only when the process
      exited during certain phases of startup. This will help adding a more
      comprehensive error extraction for early qemu startup phases.
      
      This patch adds infrastructure to keep a file descriptor for the machine
      log file that will be used in case an error happens.
      8519e9ec
    • P
      qemu_process: Make qemuProcessReadLog() more versatile and reusable · 310651a5
      Peter Krempa 提交于
      Teach the function to skip character device definitions printed by qemu
      at startup in addition to libvirt log messages and make it usable from
      outside of qemu_process.c. Also add documentation about the func.
      310651a5
  2. 24 9月, 2013 29 次提交
  3. 23 9月, 2013 1 次提交