On 5/15/2018 5:39 PM, Jason Gunthorpe wrote:
On Tue, May 15, 2018 at 05:21:16PM +0300, Leon Romanovsky wrote:
From: Leon Romanovsky <leonro@xxxxxxxxxxxx>
Changelog:
v0 -> v1:
* Dropped few validation/debug patches from the KABI part as of Jason's comments.
* Use kvmalloc/kvfree instead of kmalloc/kfree to prevent higher order allocation under user control.
* Cleaned up a dependency of CONFIG_INFINIBAND_USER_ACCESS from the uverbs layer.
* Moved to white list command mode.
* Serialize access to DEVX object - odify/read new methods were added
with the appropriate IDR lock.
* Block DEVX on IB port as of SELinux.
* Improve uverbs_cleanup_ucontext algorithm to support two objects from the same type.
* Fix mlx5_ifc.h to use reserved_at_xxx.
* Enforce devx_uid existence upon DEVX methods.
From Yishai:
This DEVX series enables direct access from the user space area to the
mlx5 device driver by using the KABI mechanism.
The main purpose here is to make the user space driver as independent as
possible from the kernel so that future device functionality and commands
can be activated with minimal to none kernel changes.
The series keeps the same level of user process security/isolation as
provided today by the kernel IB verbs by using a user id returned from
the firmware upon context creation.
This user id is put by the kernel code in all firmware command from the
DEVX interface so that the isolation/security will be enforced by the
firmware based on that id.
Below kernel services are exposed to let the above work:
1) Expose a DEVX object that represent some underlay firmware object,
the input command to create it is some raw data given by the user
application which should match the device specification.
2) Expose a UMEM DEVX object for user memory registration for DMA:
The driver provides an API to register user memory, getting as input the
user address, length and access flags, and provides to the user as output
an ID (UMEM ID) returned by the firmware to this registered memory.
The user will use that UMEM ID in device direct commands that use this
memory instead of the physical addresses list.
3) Expose device general command API:
The driver provides an API to issue some general command except than
create and destroy.
4) UAR mapping:
Returns a device UAR ID for a given user index by using the kernel
context information.
This is safe from security point of view as described in details in the
relevant patch in the series.
5) EQ mapping:
Returns the matching device EQN for a given user vector number via the
DEVX interface.
6) Process resources cleanup:
This is achieved by the existing kernel KABI logic, upon DEVX object
creation the kernel builds the FW destroy command inbox in the KABI
object and uses it upon cleanup.
7) Future device commands:
This will be supported by some general command type (create, destroy)
that the DEVX code embeds as part of its code and is going to be
used from now on by the firmware.
At the beginning of this series there are some KABI infra-structures
improvements and fixes to enable the above DEVX functionality in a
cleaner way.
More details appear as part of the commit logs of the series and as part
of the comments in the code itself.
Where is the userspace URL for this?
The below URL [1] is the DEVX user space API and implementation.
It is a special project that is embedded by an in-progress project of
DPDK [2]. This part mainly uses the IOCTL/KABI interface to work with
the kernel part of DEVX.
[1]
https://github.com/Mellanox/devx/tree/ee037e171328d2e1f2d98f96b0ecff8712929670
[2]
https://github.com/orikam/dpdk.org/tree/mdev/drivers/net/mlx5_mdev
The below URL [3] is the code as part of the DPDK project that uses the
above DEVX API.
[3]
https://github.com/orikam/dpdk.org/blob/mdev/drivers/net/mlx5_mdev/mlx5_prm_commands.c
Note:
We are still considering whether the above user space parts will go to
rdma-core with/without staying also in the DPDK area.
Yishai
--
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
