1. 28 1月, 2022 1 次提交
  2. 05 1月, 2022 1 次提交
  3. 18 12月, 2021 5 次提交
    • B
      iavf: Restrict maximum VLAN filters for VIRTCHNL_VF_OFFLOAD_VLAN_V2 · 92fc5085
      Brett Creeley 提交于
      For VIRTCHNL_VF_OFFLOAD_VLAN, PF's would limit the number of VLAN
      filters a VF was allowed to add. However, by the time the opcode failed,
      the VLAN netdev had already been added. VIRTCHNL_VF_OFFLOAD_VLAN_V2
      added the ability for a PF to tell the VF how many VLAN filters it's
      allowed to add. Make changes to support that functionality.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      92fc5085
    • B
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 offload enable/disable · 8afadd1c
      Brett Creeley 提交于
      The new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability added support that allows
      the VF to support 802.1Q and 802.1ad VLAN insertion and stripping if
      successfully negotiated via VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS.
      Multiple changes were needed to support this new functionality.
      
      1. Added new aq_required flags to support any kind of VLAN stripping and
         insertion offload requests via virtchnl.
      
      2. Added the new method iavf_set_vlan_offload_features() that's
         used during VF initialization, VF reset, and iavf_set_features() to
         set the aq_required bits based on the current VLAN offload
         configuration of the VF's netdev.
      
      3. Added virtchnl handling for VIRTCHNL_OP_ENABLE_STRIPPING_V2,
         VIRTCHNL_OP_DISABLE_STRIPPING_V2, VIRTCHNL_OP_ENABLE_INSERTION_V2,
         and VIRTCHNL_OP_ENABLE_INSERTION_V2.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      8afadd1c
    • B
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 hotpath · ccd219d2
      Brett Creeley 提交于
      The new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability added support that allows
      the PF to set the location of the Tx and Rx VLAN tag for insertion and
      stripping offloads. In order to support this functionality a few changes
      are needed.
      
      1. Add a new method to cache the VLAN tag location based on negotiated
         capabilities for the Tx and Rx ring flags. This needs to be called in
         the initialization and reset paths.
      
      2. Refactor the transmit hotpath to account for the new Tx ring flags.
         When IAVF_TXR_FLAGS_VLAN_LOC_L2TAG2 is set, then the driver needs to
         insert the VLAN tag in the L2TAG2 field of the transmit descriptor.
         When the IAVF_TXRX_FLAGS_VLAN_LOC_L2TAG1 is set, then the driver needs
         to use the l2tag1 field of the data descriptor (same behavior as
         before).
      
      3. Refactor the iavf_tx_prepare_vlan_flags() function to simplify
         transmit hardware VLAN offload functionality by only depending on the
         skb_vlan_tag_present() function. This can be done because the OS
         won't request transmit offload for a VLAN unless the driver told the
         OS it's supported and enabled.
      
      4. Refactor the receive hotpath to account for the new Rx ring flags and
         VLAN ethertypes. This requires checking the Rx ring flags and
         descriptor status bits to determine the location of the VLAN tag.
         Also, since only a single ethertype can be supported at a time, check
         the enabled netdev features before specifying a VLAN ethertype in
         __vlan_hwaccel_put_tag().
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      ccd219d2
    • B
      iavf: Add support VIRTCHNL_VF_OFFLOAD_VLAN_V2 during netdev config · 48ccc43e
      Brett Creeley 提交于
      Based on VIRTCHNL_VF_OFFLOAD_VLAN_V2, the VF can now support more VLAN
      capabilities (i.e. 802.1AD offloads and filtering). In order to
      communicate these capabilities to the netdev layer, the VF needs to
      parse its VLAN capabilities based on whether it was able to negotiation
      VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2 or neither of
      these.
      
      In order to support this, add the following functionality:
      
      iavf_get_netdev_vlan_hw_features() - This is used to determine the VLAN
      features that the underlying hardware supports and that can be toggled
      off/on based on the negotiated capabiltiies. For example, if
      VIRTCHNL_VF_OFFLOAD_VLAN_V2 was negotiated, then any capability marked
      with VIRTCHNL_VLAN_TOGGLE can be toggled on/off by the VF. If
      VIRTCHNL_VF_OFFLOAD_VLAN was negotiated, then only VLAN insertion and/or
      stripping can be toggled on/off.
      
      iavf_get_netdev_vlan_features() - This is used to determine the VLAN
      features that the underlying hardware supports and that should be
      enabled by default. For example, if VIRTHCNL_VF_OFFLOAD_VLAN_V2 was
      negotiated, then any supported capability that has its ethertype_init
      filed set should be enabled by default. If VIRTCHNL_VF_OFFLOAD_VLAN was
      negotiated, then filtering, stripping, and insertion should be enabled
      by default.
      
      Also, refactor iavf_fix_features() to take into account the new
      capabilities. To do this, query all the supported features (enabled by
      default and toggleable) and make sure the requested change is supported.
      If VIRTCHNL_VF_OFFLOAD_VLAN_V2 is successfully negotiated, there is no
      need to check VIRTCHNL_VLAN_TOGGLE here because the driver already told
      the netdev layer which features can be toggled via netdev->hw_features
      during iavf_process_config(), so only those features will be requested
      to change.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      48ccc43e
    • B
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 negotiation · 209f2f9c
      Brett Creeley 提交于
      In order to support the new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability the
      VF driver needs to rework it's initialization state machine and reset
      flow. This has to be done because successful negotiation of
      VIRTCHNL_VF_OFFLOAD_VLAN_V2 requires the VF driver to perform a second
      capability request via VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS before
      configuring the adapter and its netdev.
      
      Add the VIRTCHNL_VF_OFFLOAD_VLAN_V2 bit when sending the
      VIRTHCNL_OP_GET_VF_RESOURECES message. The underlying PF will either
      support VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2 or
      neither. Both of these offloads should never be supported together.
      
      Based on this, add 2 new states to the initialization state machine:
      
      __IAVF_INIT_GET_OFFLOAD_VLAN_V2_CAPS
      __IAVF_INIT_CONFIG_ADAPTER
      
      The __IAVF_INIT_GET_OFFLOAD_VLAN_V2_CAPS state is used to request/store
      the new VLAN capabilities if and only if VIRTCHNL_VLAN_OFFLOAD_VLAN_V2
      was successfully negotiated in the __IAVF_INIT_GET_RESOURCES state.
      
      The __IAVF_INIT_CONFIG_ADAPTER state is used to configure the
      adapter/netdev after the resource requests have finished. The VF will
      move into this state regardless of whether it successfully negotiated
      VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2.
      
      Also, add a the new flag IAVF_FLAG_AQ_GET_OFFLOAD_VLAN_V2_CAPS and set
      it during VF reset. If VIRTCHNL_VF_OFFLOAD_VLAN_V2 was successfully
      negotiated then the VF will request its VLAN capabilities via
      VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS during the reset. This is needed
      because the PF may change/modify the VF's configuration during VF reset
      (i.e. modifying the VF's port VLAN configuration).
      
      This also, required the VF to call netdev_update_features() since its
      VLAN features may change during VF reset. Make sure to call this under
      rtnl_lock().
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      209f2f9c
  4. 14 12月, 2021 2 次提交
  5. 11 12月, 2021 1 次提交
    • N
      iavf: Use irq_update_affinity_hint() · 0f9744f4
      Nitesh Narayan Lal 提交于
      The driver uses irq_set_affinity_hint() for two purposes:
      
      - To set the affinity_hint which is consumed by the userspace for
        distributing the interrupts
      
      - To apply an affinity that it provides for the iavf interrupts
      
      The latter is done to ensure that all the interrupts are evenly spread
      across all available CPUs. However, since commit a0c9259d ("irq/matrix:
      Spread interrupts on allocation") the spreading of interrupts is
      dynamically performed at the time of allocation. Hence, there is no need
      for the drivers to enforce their own affinity for the spreading of
      interrupts.
      
      Also, irq_set_affinity_hint() applying the provided cpumask as an affinity
      for the interrupt is an undocumented side effect. To remove this side
      effect irq_set_affinity_hint() has been marked as deprecated and new
      interfaces have been introduced. Hence, replace the irq_set_affinity_hint()
      with the new interface irq_update_affinity_hint() that only sets the
      pointer for the affinity_hint.
      Signed-off-by: NNitesh Narayan Lal <nitesh@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Link: https://lore.kernel.org/r/20210903152430.244937-3-nitesh@redhat.com
      0f9744f4
  6. 02 12月, 2021 1 次提交
  7. 01 12月, 2021 4 次提交
  8. 20 11月, 2021 3 次提交
    • B
      iavf: Fix VLAN feature flags after VFR · 5951a2b9
      Brett Creeley 提交于
      When a VF goes through a reset, it's possible for the VF's feature set
      to change. For example it may lose the VIRTCHNL_VF_OFFLOAD_VLAN
      capability after VF reset. Unfortunately, the driver doesn't correctly
      deal with this situation and errors are seen from downing/upping the
      interface and/or moving the interface in/out of a network namespace.
      
      When setting the interface down/up we see the following errors after the
      VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF:
      
      ice 0000:51:00.1: VF 1 failed opcode 12, retval: -64 iavf 0000:51:09.1:
      Failed to add VLAN filter, error IAVF_NOT_SUPPORTED ice 0000:51:00.1: VF
      1 failed opcode 13, retval: -64 iavf 0000:51:09.1: Failed to delete VLAN
      filter, error IAVF_NOT_SUPPORTED
      
      These add/delete errors are happening because the VLAN filters are
      tracked internally to the driver and regardless of the VLAN_ALLOWED()
      setting the driver tries to delete/re-add them over virtchnl.
      
      Fix the delete failure by making sure to delete any VLAN filter tracking
      in the driver when a removal request is made, while preventing the
      virtchnl request.  This makes it so the driver's VLAN list is up to date
      and the errors are
      
      Fix the add failure by making sure the check for VLAN_ALLOWED() during
      reset is done after the VF receives its capability list from the PF via
      VIRTCHNL_OP_GET_VF_RESOURCES. If VLAN functionality is not allowed, then
      prevent requesting re-adding the filters over virtchnl.
      
      When moving the interface into a network namespace we see the following
      errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from
      the VF:
      
      iavf 0000:51:09.1 enp81s0f1v1: NIC Link is Up Speed is 25 Gbps Full Duplex
      iavf 0000:51:09.1 temp_27: renamed from enp81s0f1v1
      iavf 0000:51:09.1 mgmt: renamed from temp_27
      iavf 0000:51:09.1 dev27: set_features() failed (-22); wanted 0x020190001fd54833, left 0x020190001fd54bb3
      
      These errors are happening because we aren't correctly updating the
      netdev capabilities and dealing with ndo_fix_features() and
      ndo_set_features() correctly.
      
      Fix this by only reporting errors in the driver's ndo_set_features()
      callback when VIRTCHNL_VF_OFFLOAD_VLAN is not allowed and any attempt to
      enable the VLAN features is made. Also, make sure to disable VLAN
      insertion, filtering, and stripping since the VIRTCHNL_VF_OFFLOAD_VLAN
      flag applies to all of them and not just VLAN stripping.
      
      Also, after we process the capabilities in the VF reset path, make sure
      to call netdev_update_features() in case the capabilities have changed
      in order to update the netdev's feature set to match the VF's actual
      capabilities.
      
      Lastly, make sure to always report success on VLAN filter delete when
      VIRTCHNL_VF_OFFLOAD_VLAN is not supported. The changed flow in
      iavf_del_vlans() allows the stack to delete previosly existing VLAN
      filters even if VLAN filtering is not allowed. This makes it so the VLAN
      filter list is up to date.
      
      Fixes: 8774370d ("i40e/i40evf: support for VF VLAN tag stripping control")
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      5951a2b9
    • J
      iavf: Fix refreshing iavf adapter stats on ethtool request · 3b5bdd18
      Jedrzej Jagielski 提交于
      Currently iavf adapter statistics are refreshed only in a
      watchdog task, triggered approximately every two seconds,
      which causes some ethtool requests to return outdated values.
      
      Add explicit statistics refresh when requested by ethtool -S.
      
      Fixes: b476b003 ("iavf: Move commands processing to the separate function")
      Signed-off-by: NJan Sokolowski <jan.sokolowski@intel.com>
      Signed-off-by: NJedrzej Jagielski <jedrzej.jagielski@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      3b5bdd18
    • J
      iavf: Fix deadlock occurrence during resetting VF interface · 0cc318d2
      Jedrzej Jagielski 提交于
      System hangs if close the interface is called from the kernel during
      the interface is in resetting state.
      During resetting operation the link is closing but kernel didn't
      know it and it tried to close this interface again what sometimes
      led to deadlock.
      Inform kernel about current state of interface
      and turn off the flag IFF_UP when interface is closing until reset
      is finished.
      Previously it was most likely to hang the system when kernel
      (network manager) tried to close the interface in the same time
      when interface was in resetting state because of deadlock.
      
      Fixes: 3c8e0b98 ("i40vf: don't stop me now")
      Signed-off-by: NJaroslaw Gawin <jaroslawx.gawin@intel.com>
      Signed-off-by: NJedrzej Jagielski <jedrzej.jagielski@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      0cc318d2
  9. 16 11月, 2021 7 次提交
  10. 30 10月, 2021 2 次提交
    • P
      iavf: Fix kernel BUG in free_msi_irqs · 605ca7c5
      Przemyslaw Patynowski 提交于
      Fix driver not freeing VF's traffic irqs, prior to calling
      pci_disable_msix in iavf_remove.
      There were possible 2 erroneous states in which, iavf_close would
      not be called.
      One erroneous state is fixed by allowing netdev to register, when state
      is already running. It was possible for VF adapter to enter state loop
      from running to resetting, where iavf_open would subsequently fail.
      If user would then unload driver/remove VF pci, iavf_close would not be
      called, as the netdev was not registered, leaving traffic pcis still
      allocated.
      Fixed this by breaking loop, allowing netdev to open device when adapter
      state is __IAVF_RUNNING and it is not explicitily downed.
      Other possiblity is entering to iavf_remove from __IAVF_RESETTING state,
      where iavf_close would not free irqs, but just return 0.
      Fixed this by checking for last adapter state and then removing irqs.
      
      Kernel panic:
      [ 2773.628585] kernel BUG at drivers/pci/msi.c:375!
      ...
      [ 2773.631567] RIP: 0010:free_msi_irqs+0x180/0x1b0
      ...
      [ 2773.640939] Call Trace:
      [ 2773.641572]  pci_disable_msix+0xf7/0x120
      [ 2773.642224]  iavf_reset_interrupt_capability.part.41+0x15/0x30 [iavf]
      [ 2773.642897]  iavf_remove+0x12e/0x500 [iavf]
      [ 2773.643578]  pci_device_remove+0x3b/0xc0
      [ 2773.644266]  device_release_driver_internal+0x103/0x1f0
      [ 2773.644948]  pci_stop_bus_device+0x69/0x90
      [ 2773.645576]  pci_stop_and_remove_bus_device+0xe/0x20
      [ 2773.646215]  pci_iov_remove_virtfn+0xba/0x120
      [ 2773.646862]  sriov_disable+0x2f/0xe0
      [ 2773.647531]  ice_free_vfs+0x2f8/0x350 [ice]
      [ 2773.648207]  ice_sriov_configure+0x94/0x960 [ice]
      [ 2773.648883]  ? _kstrtoull+0x3b/0x90
      [ 2773.649560]  sriov_numvfs_store+0x10a/0x190
      [ 2773.650249]  kernfs_fop_write+0x116/0x190
      [ 2773.650948]  vfs_write+0xa5/0x1a0
      [ 2773.651651]  ksys_write+0x4f/0xb0
      [ 2773.652358]  do_syscall_64+0x5b/0x1a0
      [ 2773.653075]  entry_SYSCALL_64_after_hwframe+0x65/0xca
      
      Fixes: 22ead37f ("i40evf: Add longer wait after remove module")
      Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com>
      Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      605ca7c5
    • K
      iavf: Add helper function to go from pci_dev to adapter · 247aa001
      Karen Sornek 提交于
      Add helper function to go from pci_dev to adapter to make work simple -
      to go from a pci_dev to the adapter structure and make netdev assignment
      instead of having to go to the net_device then the adapter.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: NKaren Sornek <karen.sornek@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      247aa001
  11. 19 10月, 2021 3 次提交
  12. 07 10月, 2021 1 次提交
  13. 02 10月, 2021 1 次提交
  14. 20 8月, 2021 1 次提交
  15. 18 8月, 2021 1 次提交
  16. 10 8月, 2021 1 次提交
  17. 20 7月, 2021 2 次提交
    • S
      iavf: fix locking of critical sections · 226d5285
      Stefan Assmann 提交于
      To avoid races between iavf_init_task(), iavf_reset_task(),
      iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and
      remove functions more locking is required.
      The current protection by __IAVF_IN_CRITICAL_TASK is needed in
      additional places.
      
      - The reset task performs state transitions, therefore needs locking.
      - The adminq task acts on replies from the PF in
        iavf_virtchnl_completion() which may alter the states.
      - The init task is not only run during probe but also if a VF gets stuck
        to reinitialize it.
      - The shutdown function performs a state transition.
      - The remove function performs a state transition and also free's
        resources.
      
      iavf_lock_timeout() is introduced to avoid waiting infinitely
      and cause a deadlock. Rather unlock and print a warning.
      Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      226d5285
    • S
      iavf: do not override the adapter state in the watchdog task · 22c8fd71
      Stefan Assmann 提交于
      The iavf watchdog task overrides adapter->state to __IAVF_RESETTING
      when it detects a pending reset. Then schedules iavf_reset_task() which
      takes care of the reset.
      
      The reset task is capable of handling the reset without changing
      adapter->state. In fact we lose the state information when the watchdog
      task prematurely changes the adapter state. This may lead to a crash if
      instead of the reset task the iavf_remove() function gets called before
      the reset task.
      In that case (if we were in state __IAVF_RUNNING previously) the
      iavf_remove() function triggers iavf_close() which fails to close the
      device because of the incorrect state information.
      
      This may result in a crash due to pending interrupts.
      kernel BUG at drivers/pci/msi.c:357!
      [...]
      Call Trace:
       [<ffffffffbddf24dd>] pci_disable_msix+0x3d/0x50
       [<ffffffffc08d2a63>] iavf_reset_interrupt_capability+0x23/0x40 [iavf]
       [<ffffffffc08d312a>] iavf_remove+0x10a/0x350 [iavf]
       [<ffffffffbddd3359>] pci_device_remove+0x39/0xc0
       [<ffffffffbdeb492f>] __device_release_driver+0x7f/0xf0
       [<ffffffffbdeb49c3>] device_release_driver+0x23/0x30
       [<ffffffffbddcabb4>] pci_stop_bus_device+0x84/0xa0
       [<ffffffffbddcacc2>] pci_stop_and_remove_bus_device+0x12/0x20
       [<ffffffffbddf361f>] pci_iov_remove_virtfn+0xaf/0x160
       [<ffffffffbddf3bcc>] sriov_disable+0x3c/0xf0
       [<ffffffffbddf3ca3>] pci_disable_sriov+0x23/0x30
       [<ffffffffc0667365>] i40e_free_vfs+0x265/0x2d0 [i40e]
       [<ffffffffc0667624>] i40e_pci_sriov_configure+0x144/0x1f0 [i40e]
       [<ffffffffbddd5307>] sriov_numvfs_store+0x177/0x1d0
      Code: 00 00 e8 3c 25 e3 ff 49 c7 86 88 08 00 00 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 7b 28 e8 0d 44
      RIP  [<ffffffffbbbf1068>] free_msi_irqs+0x188/0x190
      
      The solution is to not touch the adapter->state in iavf_watchdog_task()
      and let the reset task handle the state transition.
      Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      22c8fd71
  18. 02 7月, 2021 1 次提交
  19. 24 4月, 2021 1 次提交
  20. 23 4月, 2021 1 次提交