[RFCv4 PATCH 0/2] A General Accelerator Framework, WarpDrive

[Kenneth Lee]

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 at lixom.net>
> To: Zhangfei Gao <zhangfei.gao at linaro.org>
> CC: linux-accelerators at lists.ozlabs.org
> Subject: Re: [RFCv4 PATCH 0/2] A General Accelerator Framework, WarpDrive
> Message-ID: <CAOesGMj6D4NDoU+Pns6p32BjbERnbMV3SS5ga15zpbDv1mCBFg at mail.gmail.com>
> 
> On Thu, Aug 8, 2019 at 11:20 AM Zhangfei Gao <zhangfei.gao at linaro.org> 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)