> -----Original Message-----
> From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> Sent: Tuesday, February 2, 2021 12:44 PM
> To: Tian, Kevin <kevin.t...@intel.com>
> Cc: Song Bao Hua (Barry Song) <song.bao....@hisilicon.com>; chensihang (A)
> <chensiha...@hisilicon.com>; Arnd Bergmann <a...@arndb.de>; Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; linux-kernel@vger.kernel.org;
> io...@lists.linux-foundation.org; linux...@kvack.org; Zhangfei Gao
> <zhangfei....@linaro.org>; Liguozhu (Kenneth) <liguo...@hisilicon.com>;
> linux-accelerat...@lists.ozlabs.org
> Subject: Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device
>
> On Fri, Jan 29, 2021 at 10:09:03AM +0000, Tian, Kevin wrote:
> > > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > > we would get both sharing address and stable I/O latency.
> >
> > Isn't it like a traditional MAP_DMA API (imply pinning) plus specifying
> > cpu_va of the memory pool as the iova?
>
> I think their issue is the HW can't do the cpu_va trick without also
> involving the system IOMMU in a SVA mode
>
> It really is something that belongs under some general /dev/sva as we
> talked on the vfio thread
AFAIK, there is no this /dev/sva so /dev/uacce is an uAPI
which belongs to sva.
Another option is that we add a system call like
fs/userfaultfd.c, and move the file_operations and ioctl
to the anon inode by creating fd via anon_inode_getfd().
Then nothing will be buried by uacce.
>
> Jason
Thanks
Barry
