[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210201234424.GI4718@ziepe.ca>
Date: Mon, 1 Feb 2021 19:44:24 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
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" <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
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
Jason
Powered by blists - more mailing lists