On Thu, 8 Aug 2019 12:41:08 +0200 Olof Johansson <olof@xxxxxxxxx> wrote: > On Thu, Aug 8, 2019 at 11:20 AM Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> wrote: > > > > *WarpDrive* is a general accelerator framework for the user application to > > access the hardware without going through the kernel in data path. > > > > WarpDrive is the name for the whole framework. The component in kernel > > is called uacce, meaning "Unified/User-space-access-intended Accelerator > > Framework". It makes use of the capability of IOMMU to maintain a > > unified virtual address space between the hardware and the process. > > > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA > > patchset[1], which enables IO side page fault and PASID support. > > We have keep verifying with Jean's sva/current [2] > > We also keep verifying with Eric's SMMUv3 Nested Stage patch [3] > > > > This series and related zip & qm driver as well as dummy driver for qemu test: > > https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-rc4 > > > > The library and user application: > > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current > > Hi, > > An overall comment: This isn't really an "accelerator framework" as > much as a library for drivers to implement shared device/userspace > memory regions where the hardware allows for it. In particular, it > doesn't handle device-specific resource arbitration and > (understandably) the other components needed for an actual driver. > > As such, it probably doesn't belong in drivers/misc per se, since it > is more of a library to be used *by* drivers. It also doesn't fulfill > the requirement of in-kernel interfaces having user when added, i.e. a > real driver submitted that makes use of this library and implements > the corresponding control path . The code is a bit hidden in that github branch above (not ideal!) drivers/crypto/hisilicon/zip/* I would imagine that was to allow this side of the code to be proposed as an RFC whilst we might potentially still have changes to the precursor patches. Given the kernel side of the zip driver was applied by Herbert this morning, it would be good to rebase this tree on Herbert's crypto tree and repost this series with that final patch included so it is apparent how this actually fits with a crypto driver. Much easier to understand if everything is in front of us! Thanks Jonathan > > > -Olof
