1. 16 10月, 2015 5 次提交
    • J
      qemu: Fix qemu startup check for QEMU_CAPS_OBJECT_IOTHREAD · cc2d49f9
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1249981
      
      When qemuDomainPinIOThread was added in commit id 'fb562614', a check
      for the IOThread capability was not needed since a check for iothreadpids
      covered the condition where the support for IOThreads was not present.
      The iothreadpids array was only created if qemuProcessDetectIOThreadPIDs
      was able to query the monitor for IOThreads. It would only do that if
      the QEMU_CAPS_OBJECT_IOTHREAD capability was set.
      
      However, when iothreadids were added in commit id '8d4614a5' and the
      check for iothreadpids was replaced by a search through the iothreadids[]
      array for the matching iothread_id that left open the possibility that
      an iothreadids[] array was defined, but the entries essentially pointed
      to elements with only the 'iothread_id' defined leaving the 'thread_id'
      value of 0 and eventually the cpumap entry of NULL.
      
      This was because, the original IOThreads commit id '72edaae7' only
      checked if IOThreads were defined and if the emulator had the IOThreads
      capability, then IOThread objects were added at startup. The "capability
      failure" check was only done when a disk was assigned to an IOThread in
      qemuCheckIOThreads. This was because the initial implementation had no way
      to dynamically add IOThreads, but it was possible to dynamically add a
      disk to the domain. So the decision was if the domain supported it, then
      add the IOThread objects. Then if a disk with an IOThread defined was
      added, it could check the capability and fail to add if not there. This
      just meant the 'iothreads' value was essentially ignored.
      
      Eventually commit id 'a27ed6e7' allowed for the dynamic addition and
      deletion of IOThread objects. So it was no longer necessary to generate
      IOThread objects to dynamically attach a disk to. However, the startup
      and disk check code was not modified to reflect this.
      
      This patch will move the capability failure check to when IOThread
      objects are being added to the command line. Thus a domain that has
      IOThreads defined will not be started if the emulator doesn't support
      the capability. This means when qemuCheckIOThreads is called to add
      a disk, it's no longer necessary to check the capability. Instead the
      code can use the IOThreadFind call to indicate that the IOThread
      doesn't exist.
      
      Finally because it could be possible to have a domain running with the
      iothreadids[] defined prior to this change if libvirtd is restarted each
      having mostly empty elements, qemuProcessDetectIOThreadPIDs will check
      if there are niothreadids when the QEMU_CAPS_OBJECT_IOTHREAD capability
      check fails and remove the elements and array if it exists.
      
      With these changes in place, it turns out the cputune-numatune test
      was failing because the right bit wasn't set in the test. So used the
      opportunity to fix that and create a test that would expect to fail
      with some sort of iothreads defined and used, but not having the
      correct capability.
      cc2d49f9
    • J
      qemu: Check for niothreads == 0 in qemuSetupCgroupForIOThreads · 10604cb8
      John Ferlan 提交于
      If there are no IOThreads defined, no sense making other checks
      10604cb8
    • J
      qemu: Use 'niothreadids' instead of 'iothreads' · 4f8e8887
      John Ferlan 提交于
      Although theoretically both should be the same value, the niothreadids
      should be used in favor of iothreads when performing comparisons. This
      leaves the iothreads as a purely numeric value to be saved in the config
      file.  The one exception to the rule is virDomainIOThreadIDDefArrayInit
      where the iothreadids are being generated from the iothreads count since
      iothreadids were added after initial iothreads support.
      4f8e8887
    • P
      virsh: Use 'format' argument only when specified · 4ceaa749
      Peter Krempa 提交于
      The condition checking whether --format was specified was incorrect.
      virsh crashed if the following format was used:
      
       virsh dump VM dump --format '' --memory-only
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1272301
      4ceaa749
    • D
      docs: event impl. registration before hypervisor connection · 9bf1cef7
      Dominik Perpeet 提交于
      Event implementations need to be registered before a connection to the
      Hypervisor is opened, otherwise event handling can be impaired (e.g.
      delayed messages). This fact is referenced in an e-mail [1], but should
      also be noted in the documentation of the registration functions.
      
      [1] https://www.redhat.com/archives/libvirt-users/2014-April/msg00011.html
      9bf1cef7
  2. 15 10月, 2015 10 次提交
  3. 14 10月, 2015 16 次提交
  4. 13 10月, 2015 1 次提交
    • D
      virt-host-validate: check for IOMMU support · 9139b46a
      Daniel P. Berrange 提交于
      This looks for existance of DMAR (Intel) and IVRS (AMD)
      files under /sys/firmware/acpi/tables/, as a sign that
      the platform has IOMMU present & enabled in the BIOS.
      
      If these are present and /sys/kernel/iommu_groups does
      not contain any entries this is taken as a sign that
      the kernel has not enabled the IOMMU currently.
      
      If no ACPI tables are found we can't distinguish between
      disabled in BIOS and not present in the hardware, so we
      have to give the user a generic hint.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      9139b46a
  5. 12 10月, 2015 8 次提交