linux-kernel - RE: [RFC PATCH v2] uacce: Add uacce

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Feb 2021 00:22:01 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        "Tian, Kevin" <kevin.tian@...el.com>
CC:     "chensihang (A)" <chensihang1@...ilicon.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Zhangfei Gao <zhangfei.gao@...aro.org>,
        "Liguozhu (Kenneth)" <liguozhu@...ilicon.com>,
        "linux-accelerators@...ts.ozlabs.org" 
        <linux-accelerators@...ts.ozlabs.org>
Subject: RE: [RFC PATCH v2] uacce: Add uacce_ctrl misc device



> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgg@...pe.ca]
> Sent: Tuesday, February 2, 2021 12:44 PM
> To: Tian, Kevin <kevin.tian@...el.com>
> Cc: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>; chensihang (A)
> <chensihang1@...ilicon.com>; Arnd Bergmann <arnd@...db.de>; Greg
> Kroah-Hartman <gregkh@...uxfoundation.org>; linux-kernel@...r.kernel.org;
> iommu@...ts.linux-foundation.org; linux-mm@...ck.org; Zhangfei Gao
> <zhangfei.gao@...aro.org>; Liguozhu (Kenneth) <liguozhu@...ilicon.com>;
> linux-accelerators@...ts.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