1. 15 11月, 2016 2 次提交
    • L
      qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate · 5266426b
      Laine Stump 提交于
      The nec-usb-xhci device (which is a USB3 controller) has always
      presented itself as a PCI device when plugged into a legacy PCI slot,
      and a PCIe device when plugged into a PCIe slot, but libvirt has
      always auto-assigned it to a legacy PCI slot.
      
      This patch changes that behavior to auto-assign to a PCIe slot on
      systems that have pcie-root (e.g. Q35 and aarch64/virt).
      
      Since we don't yet auto-create pcie-*-port controllers on demand, this
      means a config with an nec-xhci USB controller that has no PCI address
      assigned will also need to have an otherwise-unused pcie-*-port
      controller specified:
      
         <controller type='pci' model='pcie-root-port'/>
         <controller type='usb' model='nec-xhci'/>
      
      (this assumes there is an otherwise-unused slot on pcie-root to accept
      the pcie-root-port)
      5266426b
    • L
      qemu: assign virtio devices to PCIe slot when appropriate · c7fc151e
      Laine Stump 提交于
      libvirt previously assigned nearly all devices to a "hotpluggable"
      legacy PCI slot even on machines with a PCIe root bus (and even though
      most such machines don't even support hotplug on legacy PCI slots!)
      Forcing all devices onto legacy PCI slots means that the domain will
      need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a
      pci-bridge (to provide hotpluggable legacy PCI slots which, again,
      usually aren't hotpluggable anyway).
      
      To help reduce the need for these legacy controllers, this patch tries
      to assign virtio-1.0-capable devices to PCIe slots whenever possible,
      by setting appropriate connectFlags in
      virDomainCalculateDevicePCIConnectFlags(). Happily, when that function
      was written (just a few commits ago) it was created with a
      "virtioFlags" argument, set by both of its callers, which is the
      proper connectFlags to set for any virtio-*-pci device - depending on
      the arch/machinetype of the domain, and whether or not the qemu binary
      supports virtio-1.0, that flag will have either been set to PCI or
      PCIe. This patch merely enables the functionality by setting the flags
      for the device to whatever is in virtioFlags if the device is a
      virtio-*-pci device.
      
      NB: the first virtio video device will be placed directly on bus 0
      slot 1 rather than on a pcie-root-port due to the override for primary
      video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not
      to change that is a topic of discussion, but this patch doesn't change
      that particular behavior.
      
      NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root
      complex) does *not* support hotplug, this means that suitable
      controllers must also be in the config (i.e. either pcie-root-port, or
      pcie-downstream-port). For now, libvirt doesn't add those
      automatically, so if you put virtio devices in a config for a qemu
      that has PCIe-capable virtio devices, you'll need to add extra
      pcie-root-ports yourself. That requirement will be eliminated in a
      future patch, but for now, it's simple to do this:
      
         <controller type='pci' model='pcie-root-port'/>
         <controller type='pci' model='pcie-root-port'/>
         <controller type='pci' model='pcie-root-port'/>
         ...
      
      Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
      c7fc151e
  2. 02 11月, 2016 1 次提交
  3. 26 10月, 2016 1 次提交
  4. 24 10月, 2016 1 次提交
    • P
      domain: Add optional 'tls' attribute for TCP chardev · 0298531b
      Pavel Hrdina 提交于
      Add an optional "tls='yes|no'" attribute for a TCP chardev.
      
      For QEMU, this will allow for disabling the host config setting of the
      'chardev_tls' for a domain chardev channel by setting the value to "no" or
      to attempt to use a host TLS environment when setting the value to "yes"
      when the host config 'chardev_tls' setting is disabled, but a TLS environment
      is configured via either the host config 'chardev_tls_x509_cert_dir' or
      'default_tls_x509_cert_dir'
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      0298531b
  5. 17 10月, 2016 1 次提交
    • A
      conf: Explain some code in more detail · 61e10143
      Andrea Bolognani 提交于
      The code is entirely correct, but it still managed to trip me
      up when I first ran into it because I did not realize right away
      that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but
      rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and
      VIR_PCI_CONNECT_TYPE_PCIE_DEVICE.
      
      In order to save the next distracted traveler in PCI Address Land
      some time, document this fact with a comment. Add a test case for
      the behavior as well.
      61e10143
  6. 12 10月, 2016 4 次提交
  7. 06 10月, 2016 1 次提交
  8. 16 9月, 2016 1 次提交
    • L
      qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) · 706b5b62
      Laszlo Ersek 提交于
      Most of QEMU's PCI display device models, such as:
      
        libvirt video/model/@type  QEMU -device
        -------------------------  ------------
        cirrus                     cirrus-vga
        vga                        VGA
        qxl                        qxl-vga
        virtio                     virtio-vga
      
      come with a linear framebuffer (sometimes called "VGA compatibility
      framebuffer"). This linear framebuffer lives in one of the PCI device's
      MMIO BARs, and allows guest code (primarily: firmware drivers, and
      non-accelerated OS drivers) to display graphics with direct memory access.
      
      Due to architectural reasons on aarch64/KVM hosts, this kind of
      framebuffer doesn't / can't work in
      
        qemu-system-(arm|aarch64) -M virt
      
      machines. Cache coherency issues guarantee a corrupted / unusable display.
      The problem has been researched by several people, including kvm-arm
      maintainers, and it's been decided that the best way (practically the only
      way) to have boot time graphics for such guests is to consolidate on
      QEMU's "virtio-gpu-pci" device.
      
      >From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt
      supports
      
        <devices>
          <video>
            <model type='virtio'/>
          </video>
        </devices>
      
      but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga"
      device model. (See the qemuBuildDeviceVideoStr() function and the
      "qemuDeviceVideo" enum impl.)
      
      According to the above, this is not right for the "virt" machine type; the
      qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
      device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
      virtio device without a compatibility framebuffer, is available, and works
      fine.
      
      (The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
      for "virt" -- supports "virtio-gpu-pci", as of upstream commit
      3ef3209d3028. See
      <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)
      
      Override the default mapping of "virtio", from "virtio-vga" to
      "virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.
      
      Cc: Andrea Bolognani <abologna@redhat.com>
      Cc: Drew Jones <drjones@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Martin Kletzander <mkletzan@redhat.com>
      Suggested-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Acked-by: NMartin Kletzander <mkletzan@redhat.com>
      706b5b62
  9. 09 9月, 2016 2 次提交
  10. 04 8月, 2016 5 次提交
  11. 27 7月, 2016 1 次提交
    • P
      tests: qemuxml2xml: Avoid crash when processing an XML that fails to parse · c934f1e0
      Peter Krempa 提交于
      Failure to parse a XML that was not supposed to fail would result into a
      crash in the test suite as the vcpu bitmap would not be filled prior to
      the active XML->XML test.
      
      Skip formatting of the vcpu snippet in the fake status XML formatter in
      such case to avoid the crash. The test would fail anyways.
      c934f1e0
  12. 18 7月, 2016 1 次提交
    • J
      Allow omitting USB port · 4f903643
      Ján Tomko 提交于
      We were requiring a USB port path in the schema, but not enforcing it.
      Omitting the USB port would lead to libvirt formatting it as (null).
      Such domain cannot be started and will disappear after libvirtd restart
      (since it cannot parse back the XML).
      
      Only format the port if it has been specified and mark it as optional
      in the XML schema.
      4f903643
  13. 15 7月, 2016 1 次提交
    • J
      tests: Adjust LUKS tests to use 'volume' secret type · a8d0afc7
      John Ferlan 提交于
      Commit id's '9bbf0d7e' and '2552fec2' added some XML parsing tests
      for a LUKS volume to use a 'passphrase' secret format. After commit,
      this was deemed to be incorrect, so covert the various tests to use
      the volume usage format where the 'usage' is the path to the volume
      rather than a user defined name string.
      
      Also, removed the qemuxml2argv-luks-disk-cipher.xml since it was
      just a duplicate of qemuxml2argv-luks-disks.xml.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      a8d0afc7
  14. 12 7月, 2016 1 次提交
  15. 11 7月, 2016 2 次提交
    • P
      qemu: Add cpu ID to the vCPU pid list in the status XML · 3f57ce4a
      Peter Krempa 提交于
      Note the vcpu ID so that once we allow non-contiguous vCPU topologies it
      will be possible to pair thread id's with the vcpus.
      3f57ce4a
    • P
      tests: qemuxml2xml: Format status XML header dynamically · 7615917a
      Peter Krempa 提交于
      Status XML tests were done by prepending a constant string to an
      existing XML. With the planned changes the header will depend on data
      present in the definition rather than just on the data that was parsed.
      
      The first dynamic element in the header will be the vcpu thread list.
      Reuse and rename qemuXML2XMLPreFormatCallback for gathering the relevant
      data when checking the active XML parsing and formating and pass the
      bitmap to a newly crated header generator.
      7615917a
  16. 07 7月, 2016 1 次提交
  17. 02 7月, 2016 4 次提交
    • L
      qemu: support setting host-side IP addresses/routes · fe8567f6
      Laine Stump 提交于
      For type='ethernet' interfaces only.
      
      (This patch had been pushed earlier in
      commit 0b4645a7, but was reverted in
      commit 84d47a3c because it had been
      accidentally pushed during the freeze for release 2.0.0)
      fe8567f6
    • J
      encryption: Add <cipher> and <ivgen> to encryption · 2552fec2
      John Ferlan 提交于
      For a luks device, allow the configuration of a specific cipher to be
      used for encrypting the volume.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      2552fec2
    • J
      encryption: Add luks parsing for storageencryption · 9bbf0d7e
      John Ferlan 提交于
      Add parse and format of the luks/passphrase secret including tests for
      volume XML parsing.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      9bbf0d7e
    • J
      util: Add 'usage' for encryption · 47e88b33
      John Ferlan 提交于
      In order to use more common code and set up for a future type, modify the
      encryption secret to allow the "usage" attribute or the "uuid" attribute
      to define the secret. The "usage" in the case of a volume secret would be
      the path to the volume as dictated by the backwards compatibility brought
      on by virStorageGenerateQcowEncryption where it set up the usage field as
      the vol->target.path and didn't allow someone to provide it. This carries
      into virSecretObjListFindByUsageLocked which takes the secret usage attribute
      value from from the domain disk definition and compares it against the
      usage type from the secret definition. Since none of the code dealing
      with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
      cosmetic change. The real usage comes in a future path where the encryption
      is expanded to be a luks volume and the secret will allow definition of
      the usage field.
      
      This code will make use of the virSecretLookup{Parse|Format}Secret common code.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      47e88b33
  18. 27 6月, 2016 2 次提交
  19. 14 6月, 2016 1 次提交
  20. 09 6月, 2016 3 次提交
  21. 08 6月, 2016 3 次提交
  22. 07 6月, 2016 1 次提交