aboutsummaryrefslogtreecommitdiff
path: root/contrib/rdmacm-mux
AgeCommit message (Collapse)Author
2019-05-13Use #include "..." for our own headers, <...> for othersMarkus Armbruster
Also delete a few redundant #include. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190315145123.28030-2-armbru@redhat.com>
2019-03-16contrib/rdmacm-mux: Fix out-of-bounds riskYuval Shaia
The function get_fd extract context from the received MAD message and uses it as a key to fetch the destination fd from the mapping table. A context can be dgid in case of CM request message or comm_id in case of CM SIDR response message. When MAD message with a smaller size as expected for the message type received we are hitting out-of-bounds where we are looking for the context out of message boundaries. Fix it by validating the message size. Reported-by Sam Smith <sam.j.smith@oracle.com> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Message-Id: <20190212112347.1605-1-yuval.shaia@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19contrib/rdmacm-mux: fix clang compilationMarcel Apfelbaum
Fix Commit a5d2f6f877 (contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer). The above commit introduces a new contrib target, adding a global dependency to libumad library in case pvrdma configuration option is enabled. Clang forbids it: clang-6.0: error: -libumad: 'linker' input unused [-Werror,-Wunused-command-line-argument] Fix by limiting the scope to the rdmacm-mux target itself. Reported-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-4-marcel.apfelbaum@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19hw/rdma: modify struct initializationMarcel Apfelbaum
Do not initialize structs with {0} since some CLANG versions do not support it. Use {} construct instead. Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-3-marcel.apfelbaum@gmail.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19contrib/rdmacm-mux: remove Wno-format-truncation flagMarcel Apfelbaum
The flag is not recognized by some CLANG versions. Add proper constraints in code instead. Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-2-marcel.apfelbaum@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2018-12-22contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexerYuval Shaia
RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a given MAD class. This does not go hand-by-hand with qemu pvrdma device's requirements where each VM is MAD agent. Fix it by adding implementation of RDMA MAD multiplexer service which on one hand register as a sole MAD agent with the kernel module and on the other hand gives service to more than one VM. Design Overview: Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> ---------------- A server process is registered to UMAD framework (for this to work the rdma_cm kernel module needs to be unloaded) and creates a unix socket to listen to incoming request from clients. A client process (such as QEMU) connects to this unix socket and registers with its own GID. TX: ---- When client needs to send rdma_cm MAD message it construct it the same way as without this multiplexer, i.e. creates a umad packet but this time it writes its content to the socket instead of calling umad_send(). The server, upon receiving such a message fetch local_comm_id from it so a context for this session can be maintain and relay the message to UMAD layer by calling umad_send(). RX: ---- The server creates a worker thread to process incoming rdma_cm MAD messages. When an incoming message arrived (umad_recv()) the server, depending on the message type (attr_id) looks for target client by either searching in gid->fd table or in local_comm_id->fd table. With the extracted fd the server relays to incoming message to the client. Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>