From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DDE2EC6FD1F for ; Fri, 29 Mar 2024 12:33:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A3C294172A; Fri, 29 Mar 2024 12:33:07 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id vPWaBEA98tB4; Fri, 29 Mar 2024 12:33:06 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9187F41731 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1711715586; bh=wIKZIeh+e5/oCwD6pk6DYaEG4943zfxGLrakRseQCfc=; h=From:To:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=izl/1YUk01KIOwIQIgE+uDKdCa3LfO3gWr3NkHh+Xmh9oRvIKkLRLu4BGWoFUFUAa L2eJgNijvAz3Tmw/lEbeBpPAeVwYXure9iyrPKZjUe7t21WqE6JO14b2KvIwA588NH CgYcSOpZLZ43QFj2P3KSvUXhPGmBDYr/e/K3zmVdItrf6fvRPOGN6HTqxiDmsz8WoZ UWvL4QkaH3ul0u3MWSV6dUJv1edmwoJ/n52InTdZodfSeU7x/GGNItO2sgSRlQ4+is OwTC+GB0aKj+hmXbJpFRhjYu/WoMu11sESylZbDOIObongg4YIju1Kv0CCHYtlg6tV j1fgLV9YW9eRQ== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id 9187F41731; Fri, 29 Mar 2024 12:33:06 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id B27921BF2C6 for ; Fri, 29 Mar 2024 12:33:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9C10082CDE for ; Fri, 29 Mar 2024 12:33:04 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id 3qf8QYzNPhJB for ; Fri, 29 Mar 2024 12:33:02 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=sashal@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org 6E731813B5 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6E731813B5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6E731813B5 for ; Fri, 29 Mar 2024 12:33:02 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9C91A61926; Fri, 29 Mar 2024 12:33:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F27AEC433C7; Fri, 29 Mar 2024 12:32:59 +0000 (UTC) From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Date: Fri, 29 Mar 2024 08:31:47 -0400 Message-ID: <20240329123207.3085013-28-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240329123207.3085013-1-sashal@kernel.org> References: <20240329123207.3085013-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.1.83 Content-Transfer-Encoding: 8bit X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711715581; bh=aSBzOgThcesMCBVYD8sSDS7JOXh9jaKZ0CAgz+tz7fo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BgSV/DS9GtEYrrVc0c9FZNlU/th0nUCZD18XrvwqIFj9SbnKnCSjfVvBP44bJh330 GlCFuA2SaeGKxphOrmGraHpYGT22VDCIr8KegiRTbSZDSae17xQ4RnneR7LU8RW1/M gf7CGi6vd8Ap4oU35gJoJJeWFSunIMoPaPLJ6wf3Jr055rSRFhOWbicFkh5E1IFi43 mWNz9/6ycvv20+6aRJDy+xUW31DMiux1stVghCiuuGNdmqpG7uwyeo/7Ri8o6Lrf+s eAT7ovrvya9gFw9ImhlohUDj+2etamv0j5nM0bI4xvAoWazq+0VIF85OfGn6KHyULg Sy5Fwy8/+J/ww== X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=pass (p=none dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=BgSV/DS9 Subject: [Intel-wired-lan] [PATCH AUTOSEL 6.1 28/31] ice: use relative VSI index for VFs instead of PF VSI number X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Przemek Kitszel , davem@davemloft.net, edumazet@google.com, netdev@vger.kernel.org, Tony Nguyen , intel-wired-lan@lists.osuosl.org, Jacob Keller , kuba@kernel.org, pabeni@redhat.com, Rafal Romanowski Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" From: Jacob Keller [ Upstream commit 11fbb1bfb5bc8c98b2d7db9da332b5e568f4aaab ] When initializing over virtchnl, the PF is required to pass a VSI ID to the VF as part of its capabilities exchange. The VF driver reports this value back to the PF in a variety of commands. The PF driver validates that this value matches the value it sent to the VF. Some hardware families such as the E700 series could use this value when reading RSS registers or communicating directly with firmware over the Admin Queue. However, E800 series hardware does not support any of these interfaces and the VF's only use for this value is to report it back to the PF. Thus, there is no requirement that this value be an actual VSI ID value of any kind. The PF driver already does not trust that the VF sends it a real VSI ID. The VSI structure is always looked up from the VF structure. The PF does validate that the VSI ID provided matches a VSI associated with the VF, but otherwise does not use the VSI ID for any purpose. Instead of reporting the VSI number relative to the PF space, report a fixed value of 1. When communicating with the VF over virtchnl, validate that the VSI number is returned appropriately. This avoids leaking information about the firmware of the PF state. Currently the ice driver only supplies a VF with a single VSI. However, it appears that virtchnl has some support for allowing multiple VSIs. I did not attempt to implement this. However, space is left open to allow further relative indexes if additional VSIs are provided in future feature development. For this reason, keep the ice_vc_isvalid_vsi_id function in place to allow extending it for multiple VSIs in the future. This change will also simplify handling of live migration in a future series. Since we no longer will provide a real VSI number to the VF, there will be no need to keep track of this number when migrating to a new host. Signed-off-by: Jacob Keller Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin --- drivers/net/ethernet/intel/ice/ice_virtchnl.c | 9 ++------- drivers/net/ethernet/intel/ice/ice_virtchnl.h | 9 +++++++++ 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c index 6c03ebf81ffda..e2a737157c3dc 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c @@ -500,7 +500,7 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8 *msg) vfres->rss_lut_size = ICE_VSIQF_HLUT_ARRAY_SIZE; vfres->max_mtu = ice_vc_get_max_frame_size(vf); - vfres->vsi_res[0].vsi_id = vf->lan_vsi_num; + vfres->vsi_res[0].vsi_id = ICE_VF_VSI_ID; vfres->vsi_res[0].vsi_type = VIRTCHNL_VSI_SRIOV; vfres->vsi_res[0].num_queue_pairs = vsi->num_txq; ether_addr_copy(vfres->vsi_res[0].default_mac_addr, @@ -546,12 +546,7 @@ static void ice_vc_reset_vf_msg(struct ice_vf *vf) */ bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id) { - struct ice_pf *pf = vf->pf; - struct ice_vsi *vsi; - - vsi = ice_find_vsi(pf, vsi_id); - - return (vsi && (vsi->vf == vf)); + return vsi_id == ICE_VF_VSI_ID; } /** diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.h b/drivers/net/ethernet/intel/ice/ice_virtchnl.h index b5a3fd8adbb4e..6073d3b2d2d65 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.h +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.h @@ -18,6 +18,15 @@ */ #define ICE_MAX_MACADDR_PER_VF 18 +/* VFs only get a single VSI. For ice hardware, the VF does not need to know + * its VSI index. However, the virtchnl interface requires a VSI number, + * mainly due to legacy hardware. + * + * Since the VF doesn't need this information, report a static value to the VF + * instead of leaking any information about the PF or hardware setup. + */ +#define ICE_VF_VSI_ID 1 + struct ice_virtchnl_ops { int (*get_ver_msg)(struct ice_vf *vf, u8 *msg); int (*get_vf_res_msg)(struct ice_vf *vf, u8 *msg); -- 2.43.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B75415ECF1; Fri, 29 Mar 2024 12:33:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711715581; cv=none; b=pcaWzBqfh6Bo6cY/MsSKsU/TEzmxCTbfP9fzdjdRHvUgsPC9GbD58bdyWBRth3Xg4jVHZ+7UwHlldxpcqWai7ZgVh+mu8txJNxhJPEZ2/DdpdeFy6IfQHtwJqoE81kb8sxqMtXNcYN5P3hHQMvSF2P+t1PTceV3vDSVCP4Kfos4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711715581; c=relaxed/simple; bh=aSBzOgThcesMCBVYD8sSDS7JOXh9jaKZ0CAgz+tz7fo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Mzr6VZMhj6WDYiuBYPrn4dGjdk9aGbaEOy/mFiILmPvy0b0Fwi7bd5zOfb5okQk9CTKkcvjEvVU+TGK/QSZPSSNuwOToWgeSgxlZNXMFZmndtXiUOQUgX7OX3kiw1B2oD32TJregFUkw2Jh5ilZ6nigyLo+pdDnOoNVJ/sRTrPQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BgSV/DS9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BgSV/DS9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F27AEC433C7; Fri, 29 Mar 2024 12:32:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711715581; bh=aSBzOgThcesMCBVYD8sSDS7JOXh9jaKZ0CAgz+tz7fo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BgSV/DS9GtEYrrVc0c9FZNlU/th0nUCZD18XrvwqIFj9SbnKnCSjfVvBP44bJh330 GlCFuA2SaeGKxphOrmGraHpYGT22VDCIr8KegiRTbSZDSae17xQ4RnneR7LU8RW1/M gf7CGi6vd8Ap4oU35gJoJJeWFSunIMoPaPLJ6wf3Jr055rSRFhOWbicFkh5E1IFi43 mWNz9/6ycvv20+6aRJDy+xUW31DMiux1stVghCiuuGNdmqpG7uwyeo/7Ri8o6Lrf+s eAT7ovrvya9gFw9ImhlohUDj+2etamv0j5nM0bI4xvAoWazq+0VIF85OfGn6KHyULg Sy5Fwy8/+J/ww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jacob Keller , Przemek Kitszel , Rafal Romanowski , Tony Nguyen , Sasha Levin , jesse.brandeburg@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Subject: [PATCH AUTOSEL 6.1 28/31] ice: use relative VSI index for VFs instead of PF VSI number Date: Fri, 29 Mar 2024 08:31:47 -0400 Message-ID: <20240329123207.3085013-28-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240329123207.3085013-1-sashal@kernel.org> References: <20240329123207.3085013-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.1.83 Content-Transfer-Encoding: 8bit From: Jacob Keller [ Upstream commit 11fbb1bfb5bc8c98b2d7db9da332b5e568f4aaab ] When initializing over virtchnl, the PF is required to pass a VSI ID to the VF as part of its capabilities exchange. The VF driver reports this value back to the PF in a variety of commands. The PF driver validates that this value matches the value it sent to the VF. Some hardware families such as the E700 series could use this value when reading RSS registers or communicating directly with firmware over the Admin Queue. However, E800 series hardware does not support any of these interfaces and the VF's only use for this value is to report it back to the PF. Thus, there is no requirement that this value be an actual VSI ID value of any kind. The PF driver already does not trust that the VF sends it a real VSI ID. The VSI structure is always looked up from the VF structure. The PF does validate that the VSI ID provided matches a VSI associated with the VF, but otherwise does not use the VSI ID for any purpose. Instead of reporting the VSI number relative to the PF space, report a fixed value of 1. When communicating with the VF over virtchnl, validate that the VSI number is returned appropriately. This avoids leaking information about the firmware of the PF state. Currently the ice driver only supplies a VF with a single VSI. However, it appears that virtchnl has some support for allowing multiple VSIs. I did not attempt to implement this. However, space is left open to allow further relative indexes if additional VSIs are provided in future feature development. For this reason, keep the ice_vc_isvalid_vsi_id function in place to allow extending it for multiple VSIs in the future. This change will also simplify handling of live migration in a future series. Since we no longer will provide a real VSI number to the VF, there will be no need to keep track of this number when migrating to a new host. Signed-off-by: Jacob Keller Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin --- drivers/net/ethernet/intel/ice/ice_virtchnl.c | 9 ++------- drivers/net/ethernet/intel/ice/ice_virtchnl.h | 9 +++++++++ 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c index 6c03ebf81ffda..e2a737157c3dc 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c @@ -500,7 +500,7 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8 *msg) vfres->rss_lut_size = ICE_VSIQF_HLUT_ARRAY_SIZE; vfres->max_mtu = ice_vc_get_max_frame_size(vf); - vfres->vsi_res[0].vsi_id = vf->lan_vsi_num; + vfres->vsi_res[0].vsi_id = ICE_VF_VSI_ID; vfres->vsi_res[0].vsi_type = VIRTCHNL_VSI_SRIOV; vfres->vsi_res[0].num_queue_pairs = vsi->num_txq; ether_addr_copy(vfres->vsi_res[0].default_mac_addr, @@ -546,12 +546,7 @@ static void ice_vc_reset_vf_msg(struct ice_vf *vf) */ bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id) { - struct ice_pf *pf = vf->pf; - struct ice_vsi *vsi; - - vsi = ice_find_vsi(pf, vsi_id); - - return (vsi && (vsi->vf == vf)); + return vsi_id == ICE_VF_VSI_ID; } /** diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.h b/drivers/net/ethernet/intel/ice/ice_virtchnl.h index b5a3fd8adbb4e..6073d3b2d2d65 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.h +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.h @@ -18,6 +18,15 @@ */ #define ICE_MAX_MACADDR_PER_VF 18 +/* VFs only get a single VSI. For ice hardware, the VF does not need to know + * its VSI index. However, the virtchnl interface requires a VSI number, + * mainly due to legacy hardware. + * + * Since the VF doesn't need this information, report a static value to the VF + * instead of leaking any information about the PF or hardware setup. + */ +#define ICE_VF_VSI_ID 1 + struct ice_virtchnl_ops { int (*get_ver_msg)(struct ice_vf *vf, u8 *msg); int (*get_vf_res_msg)(struct ice_vf *vf, u8 *msg); -- 2.43.0