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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 9 Aug 2019 14:06:26 +0100
Jonathan Cameron <jonathan.cameron@xxxxxxxxxx> wrote:

> 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
Ah my email filters went and hid zhangfei's similar response
which provided more detail than I have here.

Oops.

Jonathan




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux