Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 15 Aug 2019 13:04:24 -0400
From:   Jerome Glisse <jglisse@redhat.com>
To:     Zhangfei Gao <zhangfei.gao@linaro.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org,
        linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH 0/2] A General Accelerator Framework, WarpDrive
Message-ID: <20190815170424.GA30916@redhat.com>
References: <1565775265-21212-1-git-send-email-zhangfei.gao@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1565775265-21212-1-git-send-email-zhangfei.gao@linaro.org>
User-Agent: Mutt/1.11.3 (2019-02-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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