RE: [RFC PATCH v2] uacce: Add uacce_ctrl misc device
From: Song Bao Hua (Barry Song) <hidden>
Date: 2021-02-02 00:22:51
Also in:
linux-iommu, lkml
-----Original Message----- From: Jason Gunthorpe [mailto:jgg@ziepe.ca] Sent: Tuesday, February 2, 2021 12:44 PM To: Tian, Kevin <kevin.tian@intel.com> Cc: Song Bao Hua (Barry Song) <redacted>; chensihang (A) [off-list ref]; Arnd Bergmann [off-list ref]; Greg Kroah-Hartman [off-list ref]; linux-kernel@vger.kernel.org; iommu@lists.linux-foundation.org; linux-mm@kvack.org; Zhangfei Gao [off-list ref]; Liguozhu (Kenneth) [off-list ref]; linux-accelerators@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:quoted
quoted
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