On 12/30/2015 10:27 AM, Matan Barak wrote:
On 12/29/2015 5:19 PM, Or Gerlitz wrote:
On 12/29/2015 3:24 PM, Matan Barak wrote:
@@ -905,6 +906,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev,
struct mlx4_dev_cap *dev_cap)
dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
MLX4_GET(dev_cap->bmme_flags, outbox,
QUERY_DEV_CAP_BMME_FLAGS_OFFSET);
+ if (dev_cap->bmme_flags & MLX4_FLAG_ROCE_V1_V2)
+ dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
Did you make sure that the query dev cap wrapper unsets this bit when
proxing VF queries?
In mlx4_dev_cap:
if (mlx4_is_mfunc(dev)) {
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_SENSE_SUPPORT;
dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_ROCE_V1_V2;
mlx4_dbg(dev, "RoCE V2 is not supported when SR-IOV is enabled\n");
}
mlx4_slave_cap calls mlx4_dev_cap and uses the dev_caps it queried, so
we should be safe here.
mlx4_slave_cap is part of the Linux VF driver flow, right?
So... NO, this is the Linux implementation.
You should make things robust against any guest driver.
The only way to do that is patch the command wrapper used by the PF
to filter out unwanted cap bits, see other filtering we do in
mlx4_QUERY_DEV_CAP_wrapper
Or.
if (dev_cap->bmme_flags & MLX4_FLAG_PORT_REMAP)
dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_PORT_REMAP;
MLX4_GET(field, outbox, QUERY_DEV_CAP_CONFIG_DEV_OFFSET);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
