ice: use relative VSI index for VFs instead of PF VSI number
[ 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 <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
This commit is contained in:
parent
c1363ed886
commit
c926393dc3
|
@ -496,7 +496,7 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8 *msg)
|
|||
vfres->rss_lut_size = ICE_LUT_VSI_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,
|
||||
|
@ -542,12 +542,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;
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
|
@ -19,6 +19,15 @@
|
|||
#define ICE_MAX_MACADDR_PER_VF 18
|
||||
#define ICE_FLEX_DESC_RXDID_MAX_NUM 64
|
||||
|
||||
/* 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);
|
||||
|
|
Loading…
Reference in New Issue