1. 29 1月, 2018 1 次提交
  2. 12 8月, 2017 3 次提交
    • L
      util: save the correct VF's info when using a dual port SRIOV NIC in single port mode · b67eaa63
      Laine Stump 提交于
      Mellanox ConnectX-3 dual port SRIOV NICs present a bit of a challenge
      when assigning one of their VFs to a guest using VFIO device
      assignment.
      
      These NICs have only a single PCI PF device, and that single PF has
      two netdevs sharing the single PCI address - one for port 1 and one
      for port 2. When a VF is created it can also have 2 netdevs, or it can
      be setup in "single port" mode, where the VF has only a single netdev,
      and that netdev is connected either to port 1 or to port 2.
      
      When the VF is created in dual port mode, you get/set the MAC
      address/vlan tag for the port 1 VF by sending a netlink message to the
      PF's port1 netdev, and you get/set the MAC address/vlan tag for the
      port 2 VF by sending a netlink message to the PF's port 2 netdev. (Of
      course libvirt doesn't have any way to describe MAC/vlan info for 2
      ports in a single hostdev interface, so that's a bit of a moot point)
      
      When the VF is created in single port mode, you can *set* the MAC/vlan
      info by sending a netlink message to *either* PF netdev - the driver
      is smart enough to understand that there's only a single netdev, and
      set the MAC/vlan for that netdev. When you want to *get* it, however,
      the driver is more accurate - it will return 00:00:00:00:00:00 for the
      MAC if you request it from the port 1 PF netdev when the VF was
      configured to be single port on port 2, or if you request if from the
      port 2 PF netdev when the VF was configured to be single port on port
      1.
      
      Based on this information, when *getting* the MAC/vlan info (to save
      the original setting prior to assignment), we determine the correct PF
      netdev by matching phys_port_id between VF and PF.
      
      (IMPORTANT NOTE: this implies that to do PCI device assignment of the
      VFs on dual port Mellanox cards using <interface type='hostdev'>
      (i.e. if you want the MAC address/vlan tag to be set), not only must
      the VFs be configured in single port mode, but also the VFs *must* be
      bound to the host VF net driver, and libvirt must use managed='yes')
      
      By the time libvirt is ready to set the new MAC/vlan tag, the VF has
      already been unbound from the host net driver and bound to
      vfio-pci. This isn't problematic though because, as stated earlier,
      when a VF is created in single port mode, commands to configure it can
      be sent to either the port 1 PF netdev or the port 2 PF netdev.
      
      When it is time to restore the original MAC/vlan tag, again the VF
      will *not* be bound to a host net driver, so it won't be possible to
      learn from sysfs whether to use the port 1 or port 2 PF netdev for the
      netlink commands. And again, it doesn't matter which netdev you
      use. However, we must keep in mind that we saved the original settings
      to a file called "${PF}_${VFNUM}". To solve this problem, we just
      check for the existence of ${PF1}_${VFNUM} and ${PF2}_${VFNUM}, and
      use whichever one we find (since we know that only one can be there)
      b67eaa63
    • L
      util: make virPCIGetNetName() more versatile · b3b5aa75
      Laine Stump 提交于
      A single PCI device may have multiple netdevs associated with it. Each
      of those netdevs will have a different phys_port_id entry in
      sysfs. This patch modifies virPCIGetNetName() to allow selecting one
      of the potential many netdevs in two different ways:
      
      1) by setting the "idx" argument, the caller can select the 1st (0),
      2nd (1), etc. netdev from the PCI device's net subdirectory.
      
      2) If the physPortID arg is set (to a null-terminated string) then
      virPCIGetNetName() returns the netdev that has that phys_port_id in
      the sysfs file of the same name in the netdev's directory.
      b3b5aa75
    • L
      util: Fix const'ness of 1st arg to virPCIGetNetName() · 0dc67e6d
      Laine Stump 提交于
      The first arg isn't modified in the function, so it should be const.
      0dc67e6d
  3. 14 4月, 2017 1 次提交
  4. 24 3月, 2017 2 次提交
  5. 01 12月, 2016 1 次提交
    • 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
  6. 02 5月, 2016 1 次提交
    • M
      Change virDevicePCIAddress to virPCIDeviceAddress · c36b1f7b
      Martin Kletzander 提交于
      We had both and the only difference was that the latter also included
      information about multifunction setting.  The problem with that was that
      we couldn't use functions made for only one of the structs (e.g.
      parsing).  To consolidate those two structs, use the one in virpci.h,
      include that in domain_conf.h and add the multifunction member in it.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      c36b1f7b
  7. 19 3月, 2016 1 次提交
  8. 29 1月, 2016 1 次提交
    • A
      pci: Use bool return type for some virPCIDeviceGet*() functions · 11ef5869
      Andrea Bolognani 提交于
      The affected functions are:
      
        virPCIDeviceGetManaged()
        virPCIDeviceGetUnbindFromStub()
        virPCIDeviceGetRemoveSlot()
        virPCIDeviceGetReprobe()
      
      Change their return type from unsigned int to bool: the corresponding
      members in struct _virPCIDevice are defined as bool, and even the
      corresponding virPCIDeviceSet*() functions take a bool value as input
      so there's no point in these functions having unsigned int as return
      type.
      Suggested-by: NJohn Ferlan <jferlan@redhat.com>
      11ef5869
  9. 28 1月, 2016 1 次提交
  10. 05 1月, 2016 1 次提交
    • L
      util: reduce debug log in virPCIGetVirtualFunctions() · 3d64a9d7
      Laine Stump 提交于
      Due to debug logs like this:
      
        virPCIGetDeviceAddressFromSysfsLink:2432 : Attempting to resolve device path from device link '/sys/class/net/eth1/device/virtfn6'
        logStrToLong_ui:2369 : Converted '0000:07:00.7' to unsigned int 0
        logStrToLong_ui:2369 : Converted '07:00.7' to unsigned int 7
        logStrToLong_ui:2369 : Converted '00.7' to unsigned int 0
        logStrToLong_ui:2369 : Converted '7' to unsigned int 7
        virPCIGetDeviceAddressFromSysfs:1947 : virPCIDeviceAddress 0000:07:00.7
        virPCIGetVirtualFunctions:2554 : Found virtual function 7
      
      printed *once for each SR-IOV Virtual Function* of a Physical Function
      each time libvirt retrieved the list of VFs (so if the system has 128
      VFs, there would be 900 lines of log for each call), the debug logs on
      any system with a large number of VFs was dominated by "information"
      that was possibly useful for debugging when the code was being
      written, but is now useless for debugging of any problem on a running
      system, and only serves to obscure the real useful information. This
      overkill has no place in production code, so this patch removes it.
      3d64a9d7
  11. 21 12月, 2015 2 次提交
    • A
      pci: Introduce virPCIStubDriver enumeration · 6d9cdd2a
      Andrea Bolognani 提交于
      This replaces the virPCIKnownStubs string array that was used
      internally for stub driver validation.
      
      Advantages:
      
        * possible values are well-defined
        * typos in driver names will be detected at compile time
        * avoids having several copies of the same string around
        * no error checking required when setting / getting value
      
      The names used mirror those in the
      virDomainHostdevSubsysPCIBackendType enumeration.
      6d9cdd2a
    • A
      pci: Remove 'reprobe' parameter from virPCIDeviceUnbind() · e1b24583
      Andrea Bolognani 提交于
      The value is not inspected inside the function, so it makes more
      sense for the caller to change the device's setting explicitly.
      e1b24583
  12. 15 12月, 2015 1 次提交
  13. 25 11月, 2015 1 次提交
    • L
      nodedev: report maxCount for virtual_functions capability · f391889f
      Laine Stump 提交于
      A PCI device may have the capability to setup virtual functions (VFs)
      but have them currently all disabled. Prior to this patch, if that was
      the case the the node device XML for the device wouldn't report any
      virtual_functions capability.
      
      With this patch, if a file called "sriov_totalvfs" is found in the
      device's sysfs directory, its contents will be interpreted as a
      decimal number, and that value will be reported as "maxCount" in a
      capability element of the device's XML, e.g.:
      
         <capability type='virtual_functions' maxCount='7'/>
      
      This will be reported regardless of whether or not any VFs are
      currently enabled for the device.
      
      NB: sriov_numvfs (the number of VFs currently active) is also
      available in sysfs, but that value is implied by the number of items
      in the list that is inside the capability element, so there is no
      reason to explicitly provide it as an attribute.
      
      sriov_totalvfs and sriov_numvfs are available in kernels at least as far
      back as the 2.6.32 that is in RHEL6.7, but in the case that they
      simply aren't there, libvirt will behave as it did prior to this patch
      - no maxCount will be displayed, and the virtual_functions capability
      will be absent from the device's XML when 0 VFs are enabled.
      f391889f
  14. 15 1月, 2015 1 次提交
  15. 29 7月, 2014 2 次提交
    • E
      nodedev: fix pci express memory leak · c6a4d268
      Eric Blake 提交于
      Leak introduced in commit 16ebf10f (v1.2.6), detected by valgrind:
      
      ==9816== 216 (96 direct, 120 indirect) bytes in 6 blocks are definitely lost in loss record 665 of 821
      ==9816==    at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==9816==    by 0x50836FB: virAlloc (viralloc.c:144)
      ==9816==    by 0x1DBDBE27: udevProcessPCI (node_device_udev.c:546)
      ==9816==    by 0x1DBDD79D: udevGetDeviceDetails (node_device_udev.c:1293)
      
      * src/util/virpci.h (virPCIEDeviceInfoFree): New prototype.
      * src/util/virpci.c (virPCIEDeviceInfoFree): New function.
      * src/conf/node_device_conf.c (virNodeDevCapsDefFree): Clear
      pci_express under pci case.
      (virNodeDevCapPCIDevParseXML): Avoid leak.
      * src/node_device/node_device_udev.c (udevProcessPCI): Likewise.
      * src/libvirt_private.syms (virpci.h): Export it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      c6a4d268
    • E
      nodedev: move pci express types to virpci.h · be05c141
      Eric Blake 提交于
      Finding virPCIE* code is more intuitive if located in virpci.h
      instead of node_device_conf.h.
      
      * src/conf/node_device_conf.h (virPCIELinkSpeed, virPCIELink)
      (virPCIEDeviceInfo): Move...
      * src/util/virpci.h: ...here.
      * src/conf/node_device_conf.c (virPCIELinkSpeed): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      be05c141
  16. 16 6月, 2014 1 次提交
  17. 04 3月, 2014 1 次提交
  18. 07 2月, 2014 1 次提交
    • J
      virpci: Resolve coverity issues · b60644f3
      John Ferlan 提交于
      Coverity complains about "USE_AFTER_FREE" due to how virPCIDeviceSetStubDriver
      "could" return either -1, 0, or 1 from the VIR_STRDUP() and then possibly makes
      a call to virPCIDeviceDetach().
      
      The only way this could happen is if NULL were passed as the "driver" name
      and virStrdup() returned 0.  Since the calling functions check < 0 on the
      initial function call, the 0 possibility causes Coverity to complain.
      
      To fix this - enforce that the second parameter is not NULL using
      ATTRIBUTE_NONNULL(2) for the function prototype, then in virPCIDeviceDetach
      add an sa_assert(dev->stubDriver). This will result in Coverity not complaining
      any more.
      b60644f3
  19. 20 1月, 2014 1 次提交
  20. 08 1月, 2014 1 次提交
    • O
      util: Use new array management macros · 6f989485
      Osier Yang 提交于
      Like commit 94a26c7e from Eric Blake, the old fuzzy code should
      be replaced by the new array management macros now.
      
      And the type of scsi->count should be changed into "size_t", and
      thus virSCSIDeviceListCount should return size_t instead, similar
      for vir{PCI,USB}DeviceListCount.
      6f989485
  21. 08 11月, 2013 1 次提交
  22. 27 6月, 2013 1 次提交
    • L
      pci: new iommu_group functions · 72c029d8
      Laine Stump 提交于
      Any device which belongs to an "IOMMU group" (used by vfio) will
      have links to all devices of its group listed in
      /sys/bus/pci/$device/iommu_group/devices;
      /sys/bus/pci/$device/iommu_group is actually a link to
      /sys/kernel/iommu_groups/$n, where $n is the group number (there
      will be a corresponding device node at /dev/vfio/$n once the
      devices are bound to the vfio-pci driver)
      
      The following functions are added:
      
      virPCIDeviceGetIOMMUGroupList
      
        Gets a virPCIDeviceList with one virPCIDeviceList for each device
        in the same IOMMU group as the provided virPCIDevice (a copy of the
        original device object is included in the list.
      
      virPCIDeviceAddressIOMMUGroupIterate
      
        Calls the function @actor once for each device in the group that
        contains the given virPCIDeviceAddress.
      
      virPCIDeviceAddressGetIOMMUGroupAddresses
      
        Fills in a virPCIDeviceAddressPtr * with an array of
        virPCIDeviceAddress, one for each device in the iommu group of the
        provided virPCIDeviceAddress (including a copy of the original).
      
      virPCIDeviceAddressGetIOMMUGroupNum
      
        Returns the group number as an int (a valid group number will always
        be 0 or greater).  If there is no iommu_group link in the device's
        directory (usually indicating that vfio isn't loaded), -2 will be
        returned. On any real error, -1 will be returned.
      72c029d8
  23. 26 6月, 2013 4 次提交
  24. 25 6月, 2013 2 次提交
    • L
      pci: new utility functions · 50a8d850
      Laine Stump 提交于
      * virPCIDeviceFindByIDs - find a device on a list w/o creating an object
          This makes searching for an existing device on a list lighter weight.
      
      * virPCIDeviceCopy - make a copy of an existing virPCIDevice object.
      
      * virPCIDeviceGetDriverPathAndName - construct new strings containing
          1) the name of the driver bound to this device.
          2) the full path to the sysfs config for that driver.
          (This code was lifted from virPCIDeviceUnbindFromStub, and replaced
          there with a call to this new function).
      50a8d850
    • L
      pci: change stubDriver from const char* to char* · 53e52b4a
      Laine Stump 提交于
      Previously stubDriver was always set from a string literal, so it was
      okay to use a const char * that wasn't freed when the virPCIDevice was
      freed. This will not be the case in the near future, so it is now a
      char* that is allocated in virPCIDeviceSetStubDriver() and freed
      during virPCIDeviceFree().
      53e52b4a
  25. 02 5月, 2013 1 次提交
    • L
      pci: autolearn name of stub driver, remove from arglist · e482693b
      Laine Stump 提交于
      virPCIDeviceReattach and virPCIDeviceUnbindFromStub (called by
      virPCIDeviceReattach) had previously required the name of the stub
      driver as input. This is unnecessary, because the name of the driver
      the device is currently bound to can be found by looking at the link:
      
        /sys/bus/pci/dddd:bb:ss.ff/driver
      
      Instead of requiring that the name of the expected stub driver name
      and only unbinding if that one name is matched, we no longer take a
      driver name in the arglist for either of these
      functions. virPCIDeviceUnbindFromStub just compares the name of the
      currently bound driver to a list of "well known" stubs (right now
      contains "pci-stub" and "vfio-pci" for qemu, and "pciback" for xen),
      and only performs the unbind if it's one of those devices.
      
      This allows virsh nodedevice-reattach to work properly across a
      libvirtd restart, and fixes a couple of cases where we were
      erroneously still hard-coding "pci-stub" as the drive name.
      
      For some unknown reason, virPCIDeviceReattach had been calling
      modprobe on the stub driver prior to unbinding the device. This was
      problematic because we no longer know the name of the stub driver in
      that function. However, it is pointless to probe for the stub driver
      at that time anyway - because the device is bound to the stub driver,
      we are guaranteed that it is already loaded, and so that call to
      modprobe has been removed.
      e482693b
  26. 26 4月, 2013 2 次提交
    • L
      util: new function virPCIDeviceGetVFIOGroupDev · b210208f
      Laine Stump 提交于
      Given a virPCIDevice, this function returns the path for the device
      that controls the vfio group the device belongs to,
      e.g. "/dev/vfio/15".
      b210208f
    • L
      pci: keep a stubDriver in each virPCIDevice · be64199e
      Laine Stump 提交于
      This can be set when the virPCIDevice is created and placed on a list,
      then used later when traversing the list to determine which stub
      driver to bind/unbind for managed devices.
      
      The existing Detach and Attach functions' signatures haven't been
      changed (they still accept a stub driver name in the arg list), but if
      the arg list has NULL for stub driver and one is available in the
      device's object, that will be used. (we may later deprecate and remove
      the arg from those functions).
      be64199e
  27. 15 4月, 2013 1 次提交
    • O
      Use unsigned int instead of unsigned · b1ea781e
      Osier Yang 提交于
      Though they are the same thing, mixed use of them is uncomfortable.
      "unsigned" is used a lot in old codes, this just tries to change the
      ones in utils.
      b1ea781e
  28. 11 4月, 2013 2 次提交
  29. 06 2月, 2013 1 次提交