1. 15 8月, 2017 2 次提交
  2. 14 8月, 2017 16 次提交
  3. 12 8月, 2017 9 次提交
    • L
      util: check for PF online status earlier in guest startup · 489a937e
      Laine Stump 提交于
      When using a VF from an SRIOV-capable network card in a guest (either
      in macvtap passthrough mode, or via VFIO PCI device assignment), The
      associated PF netdev must be online in order for the VF to be usable
      by the guest. The guest, however, is not able to change the state of
      the PF. And libvirt *could* set the PF online as needed, but that
      could lead to the host receiving unexpected IPv6 traffic (since the
      default for an unconfigured interface is to participate in IPv6
      autoconf). For this reason, before assigning a VF to a guest, libvirt
      verifies that the related PF netdev is online - if it isn't, then we
      log an error and don't allow the guest startup to continue.
      
      Until now, this check was done during virNetDevSetNetConfig(). This
      works nicely because the same function is called both for macvtap
      passthrough and for VFIO device assignment. But in the case of VFIO,
      the VF has already been unbound from its netdev driver by the time we
      get to virNetDevSetNetConfig(), and in the case of dual port Mellanox
      NICs that have their VFs setup in single port mode, the *only* way to
      determine the proper PF netdev to query for online status is via the
      "phys_port_id" file that is in the VF netdev's sysfs directory. *BUT*
      if we've unbound the VF from the netdev driver, then it doesn't *have*
      a netdev sysfs directory.
      
      So, in order to check the correct PF netdev for online status, this
      patch moved the check earlier in the setup, into
      virNetDevSaveNetConfig(), which is called *before* unbinding the VF
      from its netdev driver.
      
      (Note that this implies that if you are using VFIO device assignment
      for the VFs of a Mellanox NIC that has the VFs programmed in single
      port mode, you must let the VFs be bound to their net driver and use
      "managed='yes'" in the device definition. To be more specific, this is
      only true if the VFs in single port mode are using port *2* of the PF
      - if the VFs are using only port 1, then the correct PF netdev will be
      arrived at by default/chance))
      
        This resolves: https://bugzilla.redhat.com/267191
      489a937e
    • L
      util: restructure virNetDevReadNetConfig() to eliminate false error logs · 9a081683
      Laine Stump 提交于
      virHostdevRestoreNetConfig() calls virNetDevReadNetConfig() to try and
      read the "original config" of a netdev, and if that fails, it tries
      again with a different directory/netdev name. This achieves the
      desired effect (we end up finding the config wherever it may be), but
      for each failure, virNetDevReadNetConfig() places a nice error message
      in the system logs. Experience has shown that false-positive error
      logs like this lead to erroneous bug reports, and can often mislead
      those searching for *real* bugs.
      
      This patch changes virNetDevReadNetConfig() to explicitly check if the
      file exists before calling virFileReadAll(); if it doesn't exist,
      virNetDevReadNetConfig() returns a success, but leaves all the
      variables holding the results as NULL. (This makes sense if you define
      the purpose of the function as "read a netdev's config from its config
      file *if that file exists*).
      
      To take advantage of that change, the caller,
      virHostdevRestoreNetConfig() is modified to fail immediately if
      virNetDevReadNetConfig() returns an error, and otherwise to try the
      different directory/netdev name if adminMAC & vlan & MAC are all NULL
      after the preceding attempt.
      9a081683
    • 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: match phys_port_id when converting PF-netdev to/from VF-netdev · 39d136b6
      Laine Stump 提交于
      This patch updates functions in netdev.c to pay attention to
      phys_port_id. It uses the new function virNetDevGetPhysPortID() to
      learn the phys_port_id of a VF or PF, then sends that info to
      virPCIGetNetName(), which has newly been modified to take an optional
      phys_port_id.
      39d136b6
    • 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
    • L
      util: new function virNetDevGetPhysPortID() · 48f33bb5
      Laine Stump 提交于
      On Linux each network device *can* (but not necessarily *does*) have
      an attribute called phys_port_id which can be read from the file of
      that name in the netdev's sysfs directory. The examples I've seen have
      been a many-digit hexadecimal number (as an ASCII string).
      
      This value can be useful when a single PCI device is associated with
      multiple netdevs (e.g a dual port Mellanox SR-IOV NIC - this card has
      a single PCI Physical Function (PF), and that PF has two netdevs
      associated with it (the "net" subdirectory of the PF in sysfs has two
      links rather than the usual single link to a netdev directory). Each
      of the PF netdevs has a different phys_port_id. The Virtual Functions
      (VF) are similar - the PF (a PCI device) has "n" VFs (also each of
      these is a PCI device), each VF has two netdevs, and each of the VF
      netdevs points back to the VF PCI device (with the "device" entry in
      its sysfs directory) as well as having a phys_port_id matching the PF
      netdev it is associated with.
      
      virNetDevGetPhysPortID() simply attempts to read the phys_port_id for
      the given netdev and return it to the caller. If this particular
      netdev driver doesn't support phys_port_id, it returns NULL (*not* a
      NULL-terminated string, but a NULL pointer) but still counts it as a
      success.
      48f33bb5
    • I
    • D
      m4: workaround clang/glibc problem with isnan() · 1c21dd71
      Daniel P. Berrange 提交于
      When building libvirt with clang we get bogus warnings about
      'double' being promoted to 'long double' when calling isnan().
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1472437
      
      Detect this broken isnan() / compiler combination and disable
      the -Wdouble-promotion flag.
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      1c21dd71
  4. 10 8月, 2017 7 次提交
  5. 08 8月, 2017 6 次提交