1. 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
  2. 05 11月, 2015 1 次提交
  3. 29 10月, 2015 1 次提交
    • M
      network: wait for DAD to finish for bridge IPv6 addresses · 0f7436ca
      Maxim Perevedentsev 提交于
      commit db488c79 assumed that dnsmasq would complete IPv6 DAD before
      daemonizing, but in reality it doesn't wait, which creates problems
      when libvirt's bridge driver sets the matching "dummy tap device" to
      IFF_DOWN prior to DAD completing.
      
      This patch waits for DAD completion by periodically polling the kernel
      using netlink to check whether there are any IPv6 addresses assigned
      to bridge which have a 'tentative' state (if there are any in this
      state, then DAD hasn't yet finished). After DAD is finished, execution
      continues. To avoid an endless hang in case something was wrong with
      the kernel's DAD, we wait a maximum of 5 seconds.
      0f7436ca
  4. 03 9月, 2015 1 次提交
  5. 21 7月, 2015 1 次提交
    • M
      nodedev: add RDMA and tx-udp_tnl-segmentation NIC capabilities · ac3ed208
      Moshe Levi 提交于
      Adding functionality to libvirt that will allow
      it query the interface for the availability of RDMA and
      tx-udp_tnl-segmentation Offloading NIC capabilities
      
      Here is an example of the feature XML definition:
      
      <device>
      <name>net_eth4_90_e2_ba_5e_a5_45</name>
        <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path>
        <parent>pci_0000_08_00_1</parent>
        <capability type='net'>
          <interface>eth4</interface>
          <address>90:e2:ba:5e:a5:45</address>
          <link speed='10000' state='up'/>
          <feature name='rx'/>
          <feature name='tx'/>
          <feature name='sg'/>
          <feature name='tso'/>
          <feature name='gso'/>
          <feature name='gro'/>
          <feature name='rxvlan'/>
          <feature name='txvlan'/>
          <feature name='rxhash'/>
          <feature name='rdma'/>
          <feature name='txudptnl'/>
          <capability type='80203'/>
        </capability>
      </device>
      ac3ed208
  6. 22 4月, 2015 1 次提交
    • L
      util: set MAC address for VF via netlink message to PF+VF# when possible · cb3fe38c
      Laine Stump 提交于
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1113474
      
      When we set the MAC address of a network device as a part of setting
      up macvtap "passthrough" mode (where the domain has an emulated netdev
      connected to a host macvtap device that has exclusive use of the
      physical device, and sets the device MAC address to match its own,
      i.e. "<interface type='direct'> <source mode='passthrough' .../>"), we
      use ioctl(SIOCSIFHWADDR) giving it the name of that device. This is
      true even if it is an SRIOV Virtual Function (VF).
      
      But, when we are setting the MAC address / vlan ID of a VF in
      preparation for "hostdev network" passthrough (this is where we set
      the MAC address and vlan id of the VF after detaching the host net
      driver and before assigning the device to the domain with PCI
      passthrough, i.e. "<interface type='hostdev'>", we do the setting via
      a netlink RTM_SETLINK message for that VF's Physical Function (PF),
      telling it the VF# we want to change. This sets an "administratively
      changed MAC" flag for that VF in the PF's driver, and from that point
      on (until the PF driver is reloaded, *not* merely the VF driver) that
      VF's MAC address can't be changed using ioctl(SIOCSIFHWADDR) - the
      only way to change it is via the PF with RTM_SETLINK.
      
      This means that if a VF is used for hostdev passthrough, it will have
      the admin flag set, and future attempts to use that VF for macvtap
      passthrough will fail.
      
      The solution to this problem is to check if the device being used for
      macvtap passthrough is actually a VF; if so, we use the netlink
      RTM_SETLINK message to the PF to set the VF's mac address instead of
      ioctl(SIOCSIFHWADDR) directly to the VF; if not, behavior does not
      change from previously.
      
      There are three pieces to making this work:
      
      1) virNetDevMacVLan(Create|Delete)WithVPortProfile() now call
         virNetDev(Replace|Restore)NetConfig() rather than
         virNetDev(Replace|Restore)MacAddress() (simply passing -1 for VF#
         and vlanid).
      
      2) virNetDev(Replace|Restore)NetConfig() check to see if the device is
         a VF. If so, they find the PF's name and VF#, allowing them to call
         virNetDev(Replace|Restore)VfConfig().
      
      3) To prevent mixups when detaching a macvtap passthrough device that
         had been attached while running an older version of libvirt,
         virNetDevRestoreVfConfig() is potentially given the preserved name
         of the VF, and if the proper statefile for a VF can't be found in
         the stateDir (${stateDir}/${pfname}_vf${vfid}),
         virNetDevRestoreMacAddress() is called instead (which will look in
         the file named ${stateDir}/${vfname}).
      
      This problem has existed in every version of libvirt that has both
      macvtap passthrough and interface type='hostdev'. Fortunately people
      seem to use one or the other though, so it hasn't caused any real
      world problem reports.
      cb3fe38c
  7. 15 4月, 2015 2 次提交
  8. 10 4月, 2015 1 次提交
  9. 05 3月, 2015 2 次提交
    • J
      Fix build on mingw · 41c5baea
      Ján Tomko 提交于
      Last commit unconditionally included a linux-specific header.
      
      Do not do that.
      41c5baea
    • J
      SRIOV NIC offload feature discovery · c9027d8f
      James Chapman 提交于
      Adding functionality to libvirt that will allow it
      query the ethtool interface for the availability
      of certain NIC HW offload features
      
      Here is an example of the feature XML definition:
      
      <device>
      <name>net_eth4_90_e2_ba_5e_a5_45</name>
        <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path>
        <parent>pci_0000_08_00_1</parent>
        <capability type='net'>
          <interface>eth4</interface>
          <address>90:e2:ba:5e:a5:45</address>
          <link speed='10000' state='up'/>
          <feature name='rx'/>
          <feature name='tx'/>
          <feature name='sg'/>
          <feature name='tso'/>
          <feature name='gso'/>
          <feature name='gro'/>
          <feature name='rxvlan'/>
          <feature name='txvlan'/>
          <feature name='rxhash'/>
          <capability type='80203'/>
        </capability>
      </device>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      c9027d8f
  10. 03 2月, 2015 2 次提交
    • P
      virnetdev: fix some issues found by coverity and mingw builds · 8bda9035
      Pavel Hrdina 提交于
      Commit e562a61a introduced new function to get/set interface state but
      there was misuse of ATTRIBUTE_NONNULL on non-pointer attributes and also
      we need to wrap that functions by #ifdef to not break mingw build.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      8bda9035
    • L
      util: make virNetDev(Get|Set)IFFlags() static · df2cc650
      Laine Stump 提交于
      e562a61a added these two new helper functions and only used them
      within virnetdev.c, but declared them in the .h file. If some
      currently unsupported interface flags need to be accessed in the
      future, it will make more sense to write the appropriate higher level
      function rather than require us to artificially define IFF_* on some
      mythical platform that doesn't have SIOC[SG]IFFLAGS (and therefore
      doesn't have IFF_*) just so we can call virNetDevSetIFFFlags() to
      return an error.
      
      To help someone in not going down the wrong road, this patch makes the
      two helper functions static, hopefully making it less likely that
      someone will want to use them outside of virnetdev.c.
      df2cc650
  11. 30 1月, 2015 1 次提交
  12. 06 1月, 2015 3 次提交
  13. 29 10月, 2014 1 次提交
  14. 27 10月, 2014 1 次提交
    • L
      util: eliminate "use after free" in callers of virNetDevLinkDump · f9f9699f
      Laine Stump 提交于
      virNetDevLinkDump() gets a message from netlink into "resp", then
      calls nlmsg_parse() to fill the table "tb" with pointers into resp. It
      then returns tb to its caller, but not before freeing the buffer at
      resp. That means that all the callers of virNetDevLinkDump() are
      examining memory that has already been freed. This can be verified by
      filling the buffer at resp with garbage prior to freeing it (or, I
      suppose, just running libvirtd under valgrind) then performing some
      operation that calls virNetDevLinkDump().
      
      The code has been like this ever since virNetDevLinkDump() was written
      - the original author didn't notice it, and neither did later
      additional users of the function. It has only been pure luck (or maybe
      a lack of heavy load, and/or maybe an allocation algorithm in malloc()
      that delays re-use of just-freed memory) that has kept this from
      causing errors, for example when configuring a PCI passthrough or
      macvtap passthrough network interface.
      
      The solution taken in this patch is the simplest - just return resp to
      the caller along with tb, then have the caller free it after they are
      finished using the data (pointers) in tb. I alternately could have
      made a cleaner interface by creating a new struct that put tb and resp
      together along with a vir*Free() function for it, but this function is
      only used in a couple places, and I'm not sure there will be
      additional new uses of virNetDevLinkDump(), so the value of adding a
      new type, extra APIs, etc. is dubious.
      f9f9699f
  15. 07 10月, 2014 1 次提交
  16. 11 6月, 2014 1 次提交
  17. 13 3月, 2014 1 次提交
  18. 08 11月, 2013 1 次提交
  19. 15 10月, 2013 1 次提交
    • E
      maint: avoid 'const fooPtr' in virnet files · 955af4d4
      Eric Blake 提交于
      'const fooPtr' is the same as 'foo * const' (the pointer won't
      change, but it's contents can).  But in general, if an interface
      is trying to be const-correct, it should be using 'const foo *'
      (the pointer is to data that can't be changed).
      
      Fix up remaining offenders in src/util.
      
      * src/util/virnetdev.h (virNetDevSetMAC)
      (virNetDevReplaceMacAddress, virNetDevValidateConfig)
      (virNetDevReplaceNetConfig): Use intended type.
      * src/util/virnetdevbandwidth.h (virNetDevBandwidthCopy)
      (virNetDevBandwidthPlug): Likewise.
      * src/util/virnetdevmacvlan.h (virNetDevMacVLanCreate)
      (virNetDevMacVLanCreateWithVPortProfile)
      (virNetDevMacVLanDeleteWithVPortProfile)
      (virNetDevMacVLanRestartWithVPortProfile)
      (virNetDevMacVLanVPortProfileRegisterCallback): Likewise.
      * src/util/virnetdevopenvswitch.h (virNetDevOpenvswitchAddPort):
      Likewise.
      * src/util/virnetdevtap.h (virNetDevTapCreateInBridgePort):
      Likewise.
      * src/util/virnetdevvlan.h (virNetDevVlanEqual)
      (virNetDevVlanCopy): Likewise.
      * src/util/virnetdevvportprofile.h
      (virNetDevVPortProfileAssociate)
      (virNetDevVPortProfileDisassociate): Likewise.
      * src/util/virnetlink.h (virNetlinkEventRemoveCallback)
      (virNetlinkEventAddClient, virNetlinkEventRemoveClient):
      Likewise.
      * src/util/virnetdev.c (virNetDevSetMAC)
      (virNetDevReplaceMacAddress, virNetDevValidateConfig)
      (virNetDevReplaceNetConfig): Fix fallout.
      * src/util/virnetdevbandwidth.c (virNetDevBandwidthCopy)
      (virNetDevBandwidthPlug): Likewise.
      * src/util/virnetdevmacvlan.c (virNetDevMacVLanCreate)
      (virNetDevMacVLanCreateWithVPortProfile)
      (virNetDevMacVLanDeleteWithVPortProfile)
      (virNetDevMacVLanRestartWithVPortProfile)
      (virNetDevMacVLanVPortProfileRegisterCallback): Likewise.
      * src/util/virnetdevopenvswitch.c (virNetDevOpenvswitchAddPort):
      Likewise.
      * src/util/virnetdevtap.c (virNetDevTapCreateInBridgePort):
      Likewise.
      * src/util/virnetdevvlan.c (virNetDevVlanEqual)
      (virNetDevVlanCopy): Likewise.
      * src/util/virnetdevvportprofile.c
      (virNetDevVPortProfileAssociate)
      (virNetDevVPortProfileDisassociate)
      (virNetDevVPortProfileOpSetLink, virNetDevVPortProfileOpCommon)
      (virNetDevVPortProfileOp8021Qbg, virNetDevVPortProfileOp8021Qbh):
      Likewise.
      * src/util/virnetlink.c (virNetlinkEventRemoveCallback)
      (virNetlinkEventAddClient, virNetlinkEventRemoveClient):
      Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      955af4d4
  20. 22 6月, 2013 1 次提交
  21. 14 6月, 2013 1 次提交
  22. 15 5月, 2013 1 次提交
  23. 14 5月, 2013 1 次提交
    • G
      Support for static routes on a virtual bridge · ccff335f
      Gene Czarcinski 提交于
      network: static route support for <network>
      
      This patch adds the <route> subelement of <network> to define a static
      route.  the address and prefix (or netmask) attribute identify the
      destination network, and the gateway attribute specifies the next hop
      address (which must be directly reachable from the containing
      <network>) which is to receive the packets destined for
      "address/(prefix|netmask)".
      
      These attributes are translated into an "ip route add" command that is
      executed when the network is started. The command used is of the
      following form:
      
        ip route add <address>/<prefix> via <gateway> \
                     dev <virbr-bridge> proto static metric <metric>
      
      Tests are done to validate that the input data are correct.  For
      example, for a static route ip definition, the address must be a
      network address and not a host address.  Additional checks are added
      to ensure that the specified gateway is directly reachable via this
      network (i.e. that the gateway IP address is in the same subnet as one
      of the IP's defined for the network).
      
      prefix='0' is supported for both family='ipv4' address='0.0.0.0'
      netmask='0.0.0.0' or prefix='0', and for family='ipv6' address='::',
      prefix=0', although care should be taken to not override a desired
      system default route.
      
      Anytime an attempt is made to define a static route which *exactly*
      duplicates an existing static route (for example, address=::,
      prefix=0, metric=1), the following error message will be sent to
      syslog:
      
          RTNETLINK answers: File exists
      
      This can be overridden by decreasing the metric value for the route
      that should be preferred, or increasing the metric for the route that
      shouldn't be preferred (and is thus in place only in anticipation that
      the preferred route may be removed in the future).  Caution should be
      used when manipulating route metrics, especially for a default route.
      
      Note: The use of the command-line interface should be replaced by
      direct use of libnl so that error conditions can be handled better.  But,
      that is being left as an exercise for another day.
      Signed-off-by: NGene Czarcinski <gene@czarc.net>
      Signed-off-by: NLaine Stump <laine@laine.org>
      ccff335f
  24. 08 4月, 2013 1 次提交
    • D
      Avoid casts between unsigned char * and struct nlmsghdr · e95de74d
      Daniel P. Berrange 提交于
      The virNetlinkCommand() method takes an 'unsigned char **'
      parameter to be filled with the received netlink message.
      The callers then immediately cast this to 'struct nlmsghdr',
      triggering (bogus) warnings about increasing alignment
      requirements
      
      util/virnetdev.c: In function 'virNetDevLinkDump':
      util/virnetdev.c:1300:12: warning: cast increases required alignment of target type [-Wcast-align]
           resp = (struct nlmsghdr *)*recvbuf;
                  ^
      util/virnetdev.c: In function 'virNetDevSetVfConfig':
      util/virnetdev.c:1429:12: warning: cast increases required alignment of target type [-Wcast-align]
           resp = (struct nlmsghdr *)recvbuf;
      
      Since all callers cast to 'struct nlmsghdr' we can avoid
      the warning problem entirely by simply changing the
      signature of virNetlinkCommand to return a 'struct nlmsghdr **'
      instead of 'unsigned char **'. The way we do the cast inside
      virNetlinkCommand does not have any alignment issues.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      e95de74d
  25. 06 2月, 2013 1 次提交
  26. 21 12月, 2012 1 次提交
  27. 21 9月, 2012 1 次提交
  28. 18 8月, 2012 1 次提交
  29. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  30. 17 7月, 2012 1 次提交
    • S
      Convert 'raw MAC address' usages to use virMacAddr · 387117ad
      Stefan Berger 提交于
      Introduce new members in the virMacAddr 'class'
      - virMacAddrSet: set virMacAddr from a virMacAddr
      - virMacAddrSetRaw: setting virMacAddr from raw 6 byte MAC address buffer
      - virMacAddrGetRaw: writing virMacAddr into raw 6 byte MAC address buffer
      - virMacAddrCmp: comparing two virMacAddr
      - virMacAddrCmpRaw: comparing a virMacAddr with a raw 6 byte MAC address buffer
      
      then replace raw MAC addresses by replacing
      
      - 'unsigned char *' with virMacAddrPtr
      - 'unsigned char ... [VIR_MAC_BUFLEN]' with virMacAddr
      
      and introduce usage of above functions where necessary.
      387117ad
  31. 08 5月, 2012 1 次提交
    • L
      util: set src_pid for virNetlinkCommand when appropriate · cc073771
      Laine Stump 提交于
      Until now, the nl_pid of the source address of every message sent by
      virNetlinkCommand has been set to the value of getpid(). Most of the
      time this doesn't matter, and in the one case where it does
      (communication with lldpad), it previously was the proper thing to do,
      because the netlink event service (which listens on a netlink socket
      for unsolicited messages from lldpad) coincidentally always happened
      to bind with a local nl_pid == getpid().
      
      With the fix for:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=816465
      
      that particular nl_pid is now effectively a reserved value, so the
      netlink event service will always bind to something else
      (coincidentally "getpid() + (1 << 22)", but it really could be
      anything). The result is that communication between lldpad and
      libvirtd is broken (lldpad gets a "disconnected" error when it tries
      to send a directed message).
      
      The solution to this problem caused by a solution, is to query the
      netlink event service's nlhandle for its "local_port", and send that
      as the source nl_pid (but only when sending to lldpad, of course - in
      other cases we maintain the old behavior of sending getpid()).
      
      There are two cases where a message is being directed at lldpad - one
      in virNetDevLinkDump, and one in virNetDevVPortProfileOpSetLink.
      
      The case of virNetDevVPortProfileOpSetLink is simplest to explain -
      only if !nltarget_kernel, i.e. the message isn't targetted for the
      kernel, is the dst_pid set (by calling
      virNetDevVPortProfileGetLldpadPid()), so only in that case do we call
      virNetlinkEventServiceLocalPid() to set src_pid.
      
      For virNetDevLinkDump, it's a bit more complicated. The call to
      virNetDevVPortProfileGetLldpadPid() was effectively up one level (in
      virNetDevVPortProfileOpCommon), although obscured by an unnecessary
      passing of a function pointer. This patch removes the function
      pointer, and calls virNetDevVPortProfileGetLldpadPid() directly in
      virNetDevVPortProfileOpCommon - if it's doing this, it knows that it
      should also call virNetlinkEventServiceLocalPid() to set src_pid too;
      then it just passes src_pid and dst_pid down to
      virNetDevLinkDump. Since (src_pid == 0 && dst_pid == 0) implies that
      the kernel is the destination, there is no longer any need to send
      nltarget_kernel as an arg to virNetDevLinkDump, so it's been removed.
      
      The disparity between src_pid being int and dst_pid being uint32_t may
      be a bit disconcerting to some, but I didn't want to complicate
      virNetlinkEventServiceLocalPid() by having status returned separately
      from the value.
      cc073771
  32. 06 3月, 2012 1 次提交
  33. 02 3月, 2012 1 次提交
    • E
      build: use correct type for pid and similar types · 3e2c3d8f
      Eric Blake 提交于
      No thanks to 64-bit windows, with 64-bit pid_t, we have to avoid
      constructs like 'int pid'.  Our API in libvirt-qemu cannot be
      changed without breaking ABI; but then again, libvirt-qemu can
      only be used on systems that support UNIX sockets, which rules
      out Windows (even if qemu could be compiled there) - so for all
      points on the call chain that interact with this API decision,
      we require a different variable name to make it clear that we
      audited the use for safety.
      
      Adding a syntax-check rule only solves half the battle; anywhere
      that uses printf on a pid_t still needs to be converted, but that
      will be a separate patch.
      
      * cfg.mk (sc_correct_id_types): New syntax check.
      * src/libvirt-qemu.c (virDomainQemuAttach): Document why we didn't
      use pid_t for pid, and validate for overflow.
      * include/libvirt/libvirt-qemu.h (virDomainQemuAttach): Tweak name
      for syntax check.
      * src/vmware/vmware_conf.c (vmwareExtractPid): Likewise.
      * src/driver.h (virDrvDomainQemuAttach): Likewise.
      * tools/virsh.c (cmdQemuAttach): Likewise.
      * src/remote/qemu_protocol.x (qemu_domain_attach_args): Likewise.
      * src/qemu_protocol-structs (qemu_domain_attach_args): Likewise.
      * src/util/cgroup.c (virCgroupPidCode, virCgroupKillInternal):
      Likewise.
      * src/qemu/qemu_command.c(qemuParseProcFileStrings): Likewise.
      (qemuParseCommandLinePid): Use pid_t for pid.
      * daemon/libvirtd.c (daemonForkIntoBackground): Likewise.
      * src/conf/domain_conf.h (_virDomainObj): Likewise.
      * src/probes.d (rpc_socket_new): Likewise.
      * src/qemu/qemu_command.h (qemuParseCommandLinePid): Likewise.
      * src/qemu/qemu_driver.c (qemudGetProcessInfo, qemuDomainAttach):
      Likewise.
      * src/qemu/qemu_process.c (qemuProcessAttach): Likewise.
      * src/qemu/qemu_process.h (qemuProcessAttach): Likewise.
      * src/uml/uml_driver.c (umlGetProcessInfo): Likewise.
      * src/util/virnetdev.h (virNetDevSetNamespace): Likewise.
      * src/util/virnetdev.c (virNetDevSetNamespace): Likewise.
      * tests/testutils.c (virtTestCaptureProgramOutput): Likewise.
      * src/conf/storage_conf.h (_virStoragePerms): Use mode_t, uid_t,
      and gid_t rather than int.
      * src/security/security_dac.c (virSecurityDACSetOwnership): Likewise.
      * src/conf/storage_conf.c (virStorageDefParsePerms): Avoid
      compiler warning.
      3e2c3d8f
  34. 12 1月, 2012 1 次提交
    • S
      Added Function virNetDevGetVirtualFunctions · 3a0c717b
      Shradha Shah 提交于
      This functions enables us to get the Virtual Functions attached to
      a Physical function given the name of a SR-IOV physical functio.
      
      In order to accomplish the task, added a getter function pciGetDeviceAddrString
      to get the BDF of the Virtual Function in a char array.
      3a0c717b
  35. 19 11月, 2011 1 次提交