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? Jason -- 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
