1. 01 12月, 2016 4 次提交
    • L
      qemu: assign VFIO devices to PCIe addresses when appropriate · 70249927
      Laine Stump 提交于
      Although nearly all host devices that are assigned to guests using
      VFIO ("<hostdev>" devices in libvirt) are physically PCI Express
      devices, until now libvirt's PCI address assignment has always
      assigned them addresses on legacy PCI controllers in the guest, even
      if the guest's machinetype has a PCIe root bus (e.g. q35 and
      aarch64/virt).
      
      This patch tries to assign them to an address on a PCIe controller
      instead, when appropriate. First we do some preliminary checks that
      might allow setting the flags without doing any extra work, and if
      those conditions aren't met (and if libvirt is running privileged so
      that it has proper permissions), we perform the (relatively) time
      consuming task of reading the device's PCI config to see if it is an
      Express device. If this is successful, the connect flags are set based
      on the result, but if we aren't able to read the PCI config (most
      likely due to the device not being present on the system at the time
      of the check) we assume it is (or will be) an Express device, since
      that is almost always the case anyway.
      70249927
    • L
      qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags · 9b0848d5
      Laine Stump 提交于
      If libvirtd is running unprivileged, it can open a device's PCI config
      data in sysfs, but can only read the first 64 bytes. But as part of
      determining whether a device is Express or legacy PCI,
      qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future
      patch to call virPCIDeviceIsPCIExpress(), which tries to read beyond
      the first 64 bytes of the PCI config data and fails with an error log
      if the read is unsuccessful.
      
      In order to avoid creating a parallel "quiet" version of
      virPCIDeviceIsPCIExpress(), this patch passes a virQEMUDriverPtr down
      through all the call chains that initialize the
      qemuDomainFillDevicePCIConnectFlagsIterData, and saves the driver
      pointer with the rest of the iterdata so that it can be used by
      qemuDomainDeviceCalculatePCIConnectFlags(). This pointer isn't used
      yet, but will be used in an upcoming patch (that detects Express vs
      legacy PCI for VFIO assigned devices) to examine driver->privileged.
      9b0848d5
    • L
      util: new function virPCIDeviceGetConfigPath() · bfdc1451
      Laine Stump 提交于
      The path to the config file for a PCI device is conventiently stored
      in a virPCIDevice object, but that object's contents aren't directly
      visible outside of virpci.c, so we need to have an accessor function
      for it if anyone needs to look at it.
      bfdc1451
    • L
      util: new function virFileLength() · e026563f
      Laine Stump 提交于
      This new function just calls fstat() (if provided with a valid fd) or
      stat() (if fd is -1) and returns st_size (or -1 if there is an
      error). We may decide we want this function to be more complex, and
      handle things like block devices - this is a placeholder (that works)
      for any more complicated function.
      e026563f
  2. 30 11月, 2016 8 次提交
  3. 29 11月, 2016 5 次提交
  4. 28 11月, 2016 5 次提交
    • C
      storage_backend_rbd: check the return value of rados_conf_set · 17879605
      Chen Hanxiao 提交于
      We had a lot of rados_conf_set and check works.
      Use helper virStorageBackendRBDRADOSConfSet for them.
      Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
      17879605
    • P
      qemu: capabilities: Don't partially reprope caps on process reconnect · b87a1134
      Peter Krempa 提交于
      Thanks to the complex capability caching code virQEMUCapsProbeQMP was
      never called when we were starting a new qemu VM. On the other hand,
      when we are reconnecting to the qemu process we reload the capability
      list from the status XML file. This means that the flag preventing the
      function being called was not set and thus we partially reprobed some of
      the capabilities.
      
      The recent addition of CPU hotplug clears the
      QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine does not support it.
      The partial re-probe on reconnect results into attempting to call the
      unsupported command and then killing the VM.
      
      Remove the partial reprobe and depend on the stored capabilities. If it
      will be necessary to reprobe the capabilities in the future, we should
      do a full reprobe rather than this partial one.
      b87a1134
    • J
      qemu: Add support for unavailable-features · a1adfb0f
      Jiri Denemark 提交于
      QEMU 2.8.0 adds support for unavailable-features in
      query-cpu-definitions reply. The unavailable-features array lists CPU
      features which prevent a corresponding CPU model from being usable on
      current host. It can only be used when all the unavailable features are
      disabled. Empty array means the CPU model can be used without
      modifications.
      
      We can use unavailable-features for providing CPU model usability info
      in domain capabilities XML:
      
          <domainCapabilities>
            ...
            <cpu>
              <mode name='host-passthrough' supported='yes'/>
              <mode name='host-model' supported='yes'>
                <model fallback='allow'>Skylake-Client</model>
                ...
              </mode>
              <mode name='custom' supported='yes'>
                <model usable='yes'>qemu64</model>
                <model usable='yes'>qemu32</model>
                <model usable='no'>phenom</model>
                <model usable='yes'>pentium3</model>
                <model usable='yes'>pentium2</model>
                <model usable='yes'>pentium</model>
                <model usable='yes'>n270</model>
                <model usable='yes'>kvm64</model>
                <model usable='yes'>kvm32</model>
                <model usable='yes'>coreduo</model>
                <model usable='yes'>core2duo</model>
                <model usable='no'>athlon</model>
                <model usable='yes'>Westmere</model>
                <model usable='yes'>Skylake-Client</model>
                ...
              </mode>
            </cpu>
            ...
          </domainCapabilities>
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      a1adfb0f
    • J
      tests: Add QEMU 2.8.0 domain capabilities tests · fe66e2ff
      Jiri Denemark 提交于
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      fe66e2ff
    • J
      tests: Add QEMU 2.8.0 capabilities data · 047e7dd9
      Jiri Denemark 提交于
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      047e7dd9
  5. 26 11月, 2016 18 次提交