On 7/6/2012 2:26 AM, Roland Dreier wrote:
Jack Morgenstein <jackm@xxxxxxxxxxxxxxxxxx> wrote:
For security reasons (i.e., to prevent guests from sending MADs to tunnel QPs
belonging to other guests), each proxy-tunnel qp pair is assigned a unique,
reserved, qkey. These qkeys are available only for proxy and tunnel qp's --
if the guest tries to use these qkeys with other qp's, it will fail.
How does a guest OS know which Q_Key it's allowed to use? I understand
you stick the reserved Q_Keys in the privileged Q_Key area (MSB set) so
it's not an issue for applications but I don't understand how you can avoid
breaking unlucky guest OSes.
Part of my problem is I don't see anywhere that
MLX4_RESERVED_QKEY_MASK is actually used in this patch...
As you probably saw, the isolation mechanism chosen for the
authentication of the
special QP proxy/tunnel protocol between the VFs and the master is based
on these
special qkeys. The master ((in mlx4_get_parav_qkey)) makes sure that
each VF actually
uses a different qkey for its proxy/tunnel qps, and that qkey is forced
in the QPC,
such that the qkey used by the IB core in the VF is actually ignored on TX.
The reason for using qkeys and not pkeys originates from the limited amount
of pkeys which is supported by the HCA which made it non practical to
dedicate
a pkey per VF special QP offloading.
So indeed there is a chance for unlucky guest to try and make use of
qkey from
that range, but when they attempt to plug that qkey into their QPC, the
driver
running at the master will fail that out in the code section I pointed
you to. So
this failure doesn't get unnoticed.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
