1. 14 10月, 2016 2 次提交
  2. 12 10月, 2016 7 次提交
  3. 07 10月, 2016 1 次提交
    • D
      qemu: fix command line building for iommu devices · 5dee6686
      Daniel P. Berrange 提交于
      The intel-iommu device has existed since QEMU 2.2.0, but
      it was only possible to create it with -device since
      QEMU 2.7.0, thanks to:
      
        commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
        Author: Marcel Apfelbaum <marcel@redhat.com>
        Date:   Mon Jun 27 18:38:34 2016 +0300
      
          hw/iommu: enable iommu with -device
      
          Use the standard '-device intel-iommu' to create the IOMMU device.
          The legacy '-machine,iommu=on' can still be used.
      
      The libvirt capability check & command line formatting code
      is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.
      
      This fixes it to use iommu=on instead.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      5dee6686
  4. 28 9月, 2016 1 次提交
    • J
      qemu: Fix crash in qemucapsprobe · c2c43912
      Jiri Denemark 提交于
      The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with
      caps == NULL, causing the following crash:
      
          Program received signal SIGSEGV, Segmentation fault.
          #0  0x00007ffff788775f in virQEMUCapsInitHostCPUModel
              (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at
              src/qemu/qemu_capabilities.c:2969
          #1  0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal
              (caps=caps@entry=0x0, binary=<optimized out>,
              libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0,
              runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295,
              qmpOnly=true) at src/qemu/qemu_capabilities.c:4039
          #2  0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at
              tests/qemucapsprobe.c:73
      
      Caused by v2.2.0-182-g68c70118.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      c2c43912
  5. 26 9月, 2016 1 次提交
  6. 22 9月, 2016 11 次提交
  7. 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
  8. 14 9月, 2016 1 次提交
  9. 09 9月, 2016 3 次提交
  10. 06 9月, 2016 1 次提交
    • D
      qemu: allow turning off QEMU guest RAM dump globally · 90e178f8
      Daniel P. Berrange 提交于
      We already have the ability to turn off dumping of guest
      RAM via the domain XML. This is not particularly useful
      though, as it is under control of the management application.
      What is needed is a way for the sysadmin to turn off guest
      RAM defaults globally, regardless of whether the mgmt app
      provides its own way to set this in the domain XML.
      
      So this adds a 'dump_guest_core' option in /etc/libvirt/qemu.conf
      which defaults to false. ie guest RAM will never be included in
      the QEMU core dumps by default. This default is different from
      historical practice, but is considered to be more suitable as
      a default because
      
       a) guest RAM can be huge and so inflicts a DOS on the host
          I/O subsystem when dumping core for QEMU crashes
      
       b) guest RAM can contain alot of sensitive data belonging
          to the VM owner. This should not generally be copied
          around inside QEMU core dumps submitted to vendors for
          debugging
      
       c) guest RAM contents are rarely useful in diagnosing
          QEMU crashes
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      90e178f8
  11. 25 8月, 2016 1 次提交
    • P
      qemu: command: Add support for sparse vcpu topologies · 9eb9106e
      Peter Krempa 提交于
      Add support for using the new approach to hotplug vcpus using device_add
      during startup of qemu to allow sparse vcpu topologies.
      
      There are a few limitations imposed by qemu on the supported
      configuration:
      - vcpu0 needs to be always present and not hotpluggable
      - non-hotpluggable cpus need to be ordered at the beginning
      - order of the vcpus needs to be unique for every single hotpluggable
        entity
      
      Qemu also doesn't really allow to query the information necessary to
      start a VM with the vcpus directly on the commandline. Fortunately they
      can be hotplugged during startup.
      
      The new hotplug code uses the following approach:
      - non-hotpluggable vcpus are counted and put to the -smp option
      - qemu is started
      - qemu is queried for the necessary information
      - the configuration is checked
      - the hotpluggable vcpus are hotplugged
      - vcpus are started
      
      This patch adds a lot of checking code and enables the support to
      specify the individual vcpu element with qemu.
      9eb9106e
  12. 16 8月, 2016 1 次提交
  13. 10 8月, 2016 3 次提交
  14. 04 8月, 2016 4 次提交
    • M
      qemu: Enable secure boot · 9c1524a0
      Michal Privoznik 提交于
      In qemu, enabling this feature boils down to adding the following
      onto the command line:
      
        -global driver=cfi.pflash01,property=secure,value=on
      
      However, there are some constraints resulting from the
      implementation. For instance, System Management Mode (SMM) is
      required to be enabled, the machine type must be q35-2.4 or
      later, and the guest should be x86_64. While technically it is
      possible to have 32 bit guests with secure boot, some non-trivial
      CPU flags tuning is required (for instance lm and nx flags must
      be prohibited). Given complexity of our CPU driver, this is not
      trivial. Therefore I've chosen to forbid 32 bit guests for now.
      If there's ever need, we can refine the check later.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      9c1524a0
    • M
      Introduce SMM feature · d0e4be9d
      Michal Privoznik 提交于
      Since its release of 2.4.0 qemu is able to enable System
      Management Module in the firmware, or disable it. We should
      expose this capability in the XML. Unfortunately, there's no good
      way to determine whether the binary we are talking to supports
      it. I mean, if qemu's run with real machine type, the smm
      attribute can be seen in 'qom-list /machine' output. But it's not
      there when qemu's run with -M none. Therefore we're stuck with
      version based check.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      d0e4be9d
    • A
      tests: qemuxml2argv: Fix usb-too-long-port-path-invalid · ba55861a
      Andrea Bolognani 提交于
      The test case uses DO_TEST_PARSE_FLAGS_ERROR(), but doesn't
      pass any parse flag. Use DO_TEST_PARSE_ERROR() instead.
      ba55861a
    • A
      tests: qemuxml2argv: Remove useless GIC flags · fc9cf8d8
      Andrea Bolognani 提交于
      DO_TEST_FAILURE() doesn't take a GIC version, but the GIC flag
      was passed anyway. Get rid of all such occurrences.
      fc9cf8d8
  15. 27 7月, 2016 1 次提交
  16. 21 7月, 2016 1 次提交
    • J
      Auto-add one hub if there are too many USB devices · 815d98ac
      Ján Tomko 提交于
      When parsing a command line with USB devices that have
      no address specified, QEMU automatically adds a USB hub
      if the device would fill up all the available USB ports.
      
      To help most of the users, add one hub if there are more
      USB devices than available ports. For wilder configurations,
      expect the user to provide us with more hubs and/or controllers.
      815d98ac