Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [net-next PATCH 05/11] ice: move VFLR acknowledge during ice_free_vfs
Date: Tue, 15 Feb 2022 17:31:21 -0800	[thread overview]
Message-ID: <20220216013127.3263153-6-jacob.e.keller@intel.com> (raw)
In-Reply-To: <20220216013127.3263153-1-jacob.e.keller@intel.com>

After removing all VFs, the driver clears the VFLR indication for VFs.
This has been in ice since the beginning of SR-IOV support in the ice
driver.

The implementation was copied from i40e, and the motivation for the VFLR
indication clearing is described in the commit f7414531a0cf ("i40e:
acknowledge VFLR when disabling SR-IOV")

The commit explains that we need to clear the VFLR indication because
the virtual function undergoes a VFLR event. If we don't indicate that
it is complete it can cause an issue when VFs are re-enabled due to
a "phantom" VFLR.

The register block read was added under a pci_vfs_assigned check
originally. This was done because we added the check after calling
pci_disable_sriov. This was later moved to disable SRIOV earlier in the
flow so that the VF drivers could be torn down before we removed
functionality.

Move the VFLR acknowledge into the main loop that tears down VF
resources. This avoids using the tmp value for iterating over VFs
multiple times. The result will make it easier to refactor the VF array
in a future change.

It's possible we might want to modify this flow to also stop checking
pci_vfs_assigned. However, it seems reasonable to keep this change: we
should only clear the VFLR if we actually disabled SR-IOV.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
 .../net/ethernet/intel/ice/ice_virtchnl_pf.c  | 27 ++++++-------------
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index c469b32f665b..7ab4e7d4cfb7 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -536,6 +536,14 @@ void ice_free_vfs(struct ice_pf *pf)
 			ice_free_vf_res(vf);
 		}
 
+		if (!pci_vfs_assigned(pf->pdev)) {
+			u32 reg_idx, bit_idx;
+
+			reg_idx = (hw->func_caps.vf_base_id + vf->vf_id) / 32;
+			bit_idx = (hw->func_caps.vf_base_id + vf->vf_id) % 32;
+			wr32(hw, GLGEN_VFLRSTAT(reg_idx), BIT(bit_idx));
+		}
+
 		/* clear malicious info since the VF is getting released */
 		if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->malvfs,
 					ICE_MAX_VF_COUNT, vf->vf_id))
@@ -553,25 +561,6 @@ void ice_free_vfs(struct ice_pf *pf)
 	devm_kfree(dev, pf->vf);
 	pf->vf = NULL;
 
-	/* This check is for when the driver is unloaded while VFs are
-	 * assigned. Setting the number of VFs to 0 through sysfs is caught
-	 * before this function ever gets called.
-	 */
-	if (!pci_vfs_assigned(pf->pdev)) {
-		unsigned int vf_id;
-
-		/* Acknowledge VFLR for all VFs. Without this, VFs will fail to
-		 * work correctly when SR-IOV gets re-enabled.
-		 */
-		for (vf_id = 0; vf_id < tmp; vf_id++) {
-			u32 reg_idx, bit_idx;
-
-			reg_idx = (hw->func_caps.vf_base_id + vf_id) / 32;
-			bit_idx = (hw->func_caps.vf_base_id + vf_id) % 32;
-			wr32(hw, GLGEN_VFLRSTAT(reg_idx), BIT(bit_idx));
-		}
-	}
-
 	clear_bit(ICE_VF_DIS, pf->state);
 	clear_bit(ICE_FLAG_SRIOV_ENA, pf->flags);
 }
-- 
2.35.1.129.gb80121027d12


  parent reply	other threads:[~2022-02-16  1:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16  1:31 [Intel-wired-lan] [net-next PATCH 00/11] ice: convert VF storage to hash table Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 01/11] ice: refactor unwind cleanup in eswitch mode Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 02/11] ice: store VF pointer instead of VF ID Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 03/11] ice: pass num_vfs to ice_set_per_vf_res() Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 04/11] ice: move clear_malvf call in ice_free_vfs Jacob Keller
2022-02-16  1:31 ` Jacob Keller [this message]
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 06/11] ice: remove checks in ice_vc_send_msg_to_vf Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 07/11] ice: use ice_for_each_vf for iteration during removal Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 08/11] ice: convert ice_for_each_vf to include VF entry iterator Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 09/11] ice: factor VF variables to separate structure Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 10/11] ice: introduce VF accessor functions Jacob Keller
2022-02-16  1:31 ` [Intel-wired-lan] [net-next PATCH 11/11] ice: convert VF storage to hash table with krefs and RCU Jacob Keller
2022-02-16  1:43   ` Keller, Jacob E

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220216013127.3263153-6-jacob.e.keller@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox