On Tue, Jan 17, 2023 at 10:21:18AM -0400, Jason Gunthorpe wrote:

On Tue, Jan 17, 2023 at 04:14:22PM +0200, Leon Romanovsky wrote:

quoted

On Tue, Jan 17, 2023 at 09:49:28AM -0400, Jason Gunthorpe wrote:

quoted

On Tue, Jan 17, 2023 at 02:03:07PM +0200, Leon Romanovsky wrote:

quoted

On Mon, Jan 16, 2023 at 01:39:38PM -0400, Jason Gunthorpe wrote:

quoted

On Mon, Jan 16, 2023 at 03:05:50PM +0200, Leon Romanovsky wrote:

quoted

diff --git a/drivers/infiniband/hw/mlx4/mlx4_ib.h b/drivers/infiniband/hw/mlx4/mlx4_ib.h
index 17fee1e73a45..c553bf0eb257 100644
--- a/drivers/infiniband/hw/mlx4/mlx4_ib.h
+++ b/drivers/infiniband/hw/mlx4/mlx4_ib.h

@@ -184,7 +184,7 @@ enum mlx4_ib_qp_flags {
 	/* Mellanox specific flags start from IB_QP_CREATE_RESERVED_START */
 	MLX4_IB_ROCE_V2_GSI_QP = MLX4_IB_QP_CREATE_ROCE_V2_GSI,
 	MLX4_IB_SRIOV_TUNNEL_QP = 1 << 30,
-	MLX4_IB_SRIOV_SQP = 1 << 31,
+	MLX4_IB_SRIOV_SQP = 1ULL << 31,
 };

These should be moved to a uapi if we are saying they are userspace
available

But I'm not sure they are?

I don't think so.

Then they should be > 32 bits right?

Right now, they are in reserved range:
        /* reserve bits 26-31 for low level drivers' internal use */
        IB_QP_CREATE_RESERVED_START             = 1 << 26,
        IB_QP_CREATE_RESERVED_END               = 1ULL << 31,

If we move them to kernel part, we will need to define reserved range
there too. So we just "burn" extra bits just for mlx4, also I don't see
any reason to promote mlx4 bits to be general ones.

Is the reserved range kernel only? It would be nice to clarify that
detail

If yes we should move it so that userspace cannot set it. Do we have a
bug here already?

No, we always checked that users can't provide these bits and fail create QP.

It means that we can safely move that range too.

Thanks

Jason