On Thu, Aug 08, 2019 at 12:41:08PM +0200, Olof Johansson wrote: > Date: Thu, 8 Aug 2019 12:41:08 +0200 > From: Olof Johansson <olof@xxxxxxxxx> > To: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> > CC: linux-accelerators@xxxxxxxxxxxxxxxx > Subject: Re: [RFCv4 PATCH 0/2] A General Accelerator Framework, WarpDrive > Message-ID: <CAOesGMj6D4NDoU+Pns6p32BjbERnbMV3SS5ga15zpbDv1mCBFg@xxxxxxxxxxxxxx> > > 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. Hi, Guys, I'm sorry I missed the party:). I'm working on other accelerator these days. Please allow me explain the orinal idea of WarpDrive with this blog: https://zhuanlan.zhihu.com/p/79680889 > > 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. > > > -Olof -- -Kenneth(Hisilicon)
