On Thu, Aug 15, 2019 at 01:04:24PM -0400, Jerome Glisse wrote: > Date: Thu, 15 Aug 2019 13:04:24 -0400 > From: Jerome Glisse <jglisse@xxxxxxxxxx> > To: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> > CC: linux-accelerators@xxxxxxxxxxxxxxxx, Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Arnd Bergmann > <arnd@xxxxxxxx> > Subject: Re: [PATCH 0/2] A General Accelerator Framework, WarpDrive > User-Agent: Mutt/1.11.3 (2019-02-01) > Message-ID: <20190815170424.GA30916@xxxxxxxxxx> > > On Wed, Aug 14, 2019 at 05:34:23PM +0800, Zhangfei Gao 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-v1 > > zip driver already been upstreamed. > > zip supporting uacce will be the next step. > > > > The library and user application: > > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current > > Do we want a new framework ? I think that is the first question that > should be answer here. Accelerator are in many forms and so far they > never have been enough commonality to create a framework, even GPUs > with the drm is an example of that, drm only offer share framework > for the modesetting part of the GPU (as thankfully monitor connector > are not specific to GPU brands :)) > > FPGA is another example the only common code expose to userspace is > about bitstream management AFAIK. > > I would argue that a framework should only be created once there is > enough devices with same userspace API. Meanwhile you can provide > in kernel helper that allow driver to expose same API. If after a > while we have enough device driver which all use that same in kernel > helpers API then it will a good time to introduce a new framework. > Meanwhile this will allow individual device driver to tinker with > their API and maybe get to something useful to more devices in the > end. > > Note that what i propose also allow userspace code sharing for all > driver that use the same in kernel helper. > > Cheers, > Jérôme Hi, Jerome, I explain the idea here: https://zhuanlan.zhihu.com/p/79680889. We think this is a comment requirement for eveybody. Hope this can help the discussion. Thanks -- -Kenneth(Hisilicon)
