Re: [PATCH net-next 09/13] net/mlx5: E-switch, derive manager vport from device capability

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] mlx5: VF manager vport left disabled during eswitch init
- [High] mlx5: steering subsystems misidentify VF manager due to hardcoded vport
--

commit b7db8f67187916a60362e41344e85b321363810d
Author: Shay Drory <shayd@nvidia.com>

net/mlx5: E-switch, derive manager vport from device capability

mlx5_eswitch_manager_vport() hardcoded the e-switch manager vport as
either the ECPF or the host PF. Read esw_manager_vport_number from the
e-switch capability when esw_manager_vport_number_valid is set, so the
manager vport can be a VF - a prerequisite for VFs acting as e-switch
managers. Keep the previous mapping as fallback when the capability does
not report a number.

> diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h
> index a0dd162baa787..03d3620141c83 100644
> --- a/include/linux/mlx5/eswitch.h
> +++ b/include/linux/mlx5/eswitch.h
> @@ -222,6 +222,9 @@ static inline bool is_mdev_switchdev_mode(struct mlx5_core_dev *dev)
>  /* The returned number is valid only when the dev is eswitch manager. */
>  static inline u16 mlx5_eswitch_manager_vport(struct mlx5_core_dev *dev)
>  {
> +	if (MLX5_CAP_ESW(dev, esw_manager_vport_number_valid))
> +		return MLX5_CAP_ESW(dev, esw_manager_vport_number);
> +

[Severity: High]
With this change allowing a VF to be the e-switch manager, does it break
initialization in mlx5_eswitch_enable_pf_vf_vports()?

Looking at drivers/net/ethernet/mellanox/mlx5/core/eswitch.c, that function
hardcodes loading only MLX5_VPORT_HOST_PF and MLX5_VPORT_ECPF:

	/* Enable ECPF vport */
	if (mlx5_ecpf_vport_exists(esw->dev)) {
		ret = mlx5_eswitch_load_pf_vf_vport(esw, MLX5_VPORT_ECPF, enabled_events);
		if (ret)
			goto ecpf_err;
	}

Since a VF doesn't have its own VFs (num_vfs == 0), the iteration over VFs
skips it as well. Without a direct call to load esw->manager_vport, does the VF
manager vport remain disabled?

Similarly, the teardown path in mlx5_eswitch_disable_pf_vf_vports()
hardcodes unloads for ECPF and HOST_PF, omitting the VF manager vport if it
had been loaded.

[Severity: High]
Does returning a VF manager vport here also break steering subsystems that
hardcode the manager vport ID?

In drivers/net/ethernet/mellanox/mlx5/core/steering/hws/vport.c:

static bool hws_vport_is_esw_mgr_vport(struct mlx5hws_context *ctx, u16 vport)
{
	return ctx->caps->is_ecpf ? vport == MLX5_VPORT_ECPF :
				    vport == MLX5_VPORT_HOST_PF;
}

And similarly in drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c:

static bool dr_domain_is_esw_mgr_vport(struct mlx5dr_domain *dmn, u16 vport)
{
	struct mlx5dr_cmd_caps *caps = &dmn->info.caps;

	return (caps->is_ecpf && vport == MLX5_VPORT_ECPF) ||
	       (!caps->is_ecpf && vport == 0);
}

Both functions falsely assume the manager vport is MLX5_VPORT_HOST_PF (0) for
non-ECPF devices, which would return false for a VF manager. 

Will this cause the driver to query the manager's own capabilities and GVMI
using firmware commands designed for other vports, leading to GVMI resolution
failures and packet misrouting?

>  	return mlx5_core_is_ecpf_esw_manager(dev) ?
>  		MLX5_VPORT_ECPF : MLX5_VPORT_HOST_PF;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923103830.1183-1-tariqt@nvidia.com?part=9