Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
On Thu, Aug 02, 2018 at 04:36:52AM +, Tian, Kevin wrote: > Date: Thu, 2 Aug 2018 04:36:52 + > From: "Tian, Kevin" > To: Kenneth Lee > CC: Kenneth Lee , Herbert Xu > , "k...@vger.kernel.org" > , Jonathan Corbet , Greg > Kroah-Hartman , "linux-...@vger.kernel.org" > , "Kumar, Sanjay K" , > Hao Fang , "iommu@lists.linux-foundation.org" > , "linux-ker...@vger.kernel.org" > , "linux...@huawei.com" > , Alex Williamson , > Thomas Gleixner , "linux-cry...@vger.kernel.org" > , Philippe Ombredanne > , Zaibo Xu , "David S . Miller" > , "linux-accelerat...@lists.ozlabs.org" > > Subject: RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive > Message-ID: > > > > From: Kenneth Lee > > Sent: Thursday, August 2, 2018 11:40 AM > > > > On Thu, Aug 02, 2018 at 02:59:33AM +, Tian, Kevin wrote: > > > > From: Kenneth Lee > > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > > > From: Kenneth Lee > > > > > > > > WarpDrive is an accelerator framework to expose the hardware > > capabilities > > > > directly to the user space. It makes use of the exist vfio and vfio-mdev > > > > facilities. So the user application can send request and DMA to the > > > > hardware without interaction with the kernel. This remove the latency > > > > of syscall and context switch. > > > > > > > > The patchset contains documents for the detail. Please refer to it for > > more > > > > information. > > > > > > > > This patchset is intended to be used with Jean Philippe Brucker's SVA > > > > patch [1] (Which is also in RFC stage). But it is not mandatory. This > > > > patchset is tested in the latest mainline kernel without the SVA > > > > patches. > > > > So it support only one process for each accelerator. > > > > > > If no sharing, then why not just assigning the whole parent device to > > > the process? IMO if SVA usage is the clear goal of your series, it > > > might be made clearly so then Jean's series is mandatory dependency... > > > > > > > We don't know how SVA will be finally. But the feature, "make use of > > per-PASID/substream ID IOMMU page table", should be able to be enabled > > in the > > kernel. So we don't want to enforce it here. After we have this serial > > ready, > > it > > can be hooked to any implementation. > > "any" or "only queue-based" implementation? some devices may not > have queue concept, e.g. GPU. Here, "any implementation" refer to the "per PASID page table" implementatin:) > > > > > Further more, even without "per-PASID IOMMU page table", this series has > > its > > value. It is not simply dedicate the whole device to the process. It > > "shares" > > the device with the kernel driver. So you can support crypto and a user > > application at the same time. > > OK. > > Thanks > Kevin -- -Kenneth(Hisilicon) 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive framework
> From: Kenneth Lee > Sent: Thursday, August 2, 2018 12:23 PM > > On Thu, Aug 02, 2018 at 03:14:38AM +, Tian, Kevin wrote: > > > > > From: Kenneth Lee > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > From: Kenneth Lee > > > > > > WarpDrive is a common user space accelerator framework. Its main > > > component > > > in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It > > > > Not sure whether "share parent IOMMU" is a good term here. better > > stick to what capabity you bring to user space, instead of describing > > internal trick... > Agree. The "SPI" is also strongly hint to "Share Peripheral Interrupt" or > "Serial > Peripheral Interface". Personally I hate this name. But I cannot find a better > one. In the user space, we can use a impassible name (WarpDrive). But > kernel > require a name point to its feature... maybe I should use "Process-Shared > Mdev" > in next version? or maybe no new name. Just stick to mdev but introducing some new attribute/capability to indicate such purpose. Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 2/7] iommu: Add share domain interface in iommu for spimdev
> From: Kenneth Lee > Sent: Thursday, August 2, 2018 12:16 PM > > On Thu, Aug 02, 2018 at 03:17:03AM +, Tian, Kevin wrote: > > > From: Kenneth Lee > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > From: Kenneth Lee > > > > > > This patch add sharing interface for a iommu_group. The new interface: > > > > > > iommu_group_share_domain() > > > iommu_group_unshare_domain() > > > > > > can be used by some virtual iommu_group (such as iommu_group for > > > spimdev) > > > to share their parent's iommu_group. > > > > > > When the domain of the group is shared, it cannot be changed before > > > unshared. In the future, notification can be added if update is required. > > > > Is it necessary or just asking VFIO to use parent domain directly? > > > Even we add to VFIO, the iommu still need to be changed. We can move > the type1 > part to VFIO if we have agreement in RFC stage. We have similar consideration in IOMMU aware mdev series. Now we are inclined to avoid faked entity within IOMMU layer - leave to caller to figure out right physical entity for any IOMMU ops. That might be leveraged here too after we get a new version. Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
> From: Kenneth Lee > Sent: Thursday, August 2, 2018 11:40 AM > > On Thu, Aug 02, 2018 at 02:59:33AM +, Tian, Kevin wrote: > > > From: Kenneth Lee > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > From: Kenneth Lee > > > > > > WarpDrive is an accelerator framework to expose the hardware > capabilities > > > directly to the user space. It makes use of the exist vfio and vfio-mdev > > > facilities. So the user application can send request and DMA to the > > > hardware without interaction with the kernel. This remove the latency > > > of syscall and context switch. > > > > > > The patchset contains documents for the detail. Please refer to it for > more > > > information. > > > > > > This patchset is intended to be used with Jean Philippe Brucker's SVA > > > patch [1] (Which is also in RFC stage). But it is not mandatory. This > > > patchset is tested in the latest mainline kernel without the SVA patches. > > > So it support only one process for each accelerator. > > > > If no sharing, then why not just assigning the whole parent device to > > the process? IMO if SVA usage is the clear goal of your series, it > > might be made clearly so then Jean's series is mandatory dependency... > > > > We don't know how SVA will be finally. But the feature, "make use of > per-PASID/substream ID IOMMU page table", should be able to be enabled > in the > kernel. So we don't want to enforce it here. After we have this serial ready, > it > can be hooked to any implementation. "any" or "only queue-based" implementation? some devices may not have queue concept, e.g. GPU. > > Further more, even without "per-PASID IOMMU page table", this series has > its > value. It is not simply dedicate the whole device to the process. It "shares" > the device with the kernel driver. So you can support crypto and a user > application at the same time. OK. Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 3/7] vfio: add spimdev support
> From: Kenneth Lee [mailto:liguo...@hisilicon.com] > Sent: Thursday, August 2, 2018 11:47 AM > > > > > > From: Kenneth Lee > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > From: Kenneth Lee > > > > > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ > from > > > the general vfio-mdev: > > > > > > 1. It shares its parent's IOMMU. > > > 2. There is no hardware resource attached to the mdev is created. The > > > hardware resource (A `queue') is allocated only when the mdev is > > > opened. > > > > Alex has concern on doing so, as pointed out in: > > > > https://www.spinics.net/lists/kvm/msg172652.html > > > > resource allocation should be reserved at creation time. > > Yes. That is why I keep telling that SPIMDEV is not for "VM", it is for "many > processes", it is just an access point to the process. Not a device to VM. I > hope > Alex can accept it:) > VFIO is just about assigning device resource to user space. It doesn't care whether it's native processes or VM using the device so far. Along the direction which you described, looks VFIO needs to support the configuration that some mdevs are used for native process only, while others can be used for both native and VM. I'm not sure whether there is a clean way to enforce it... Let's hear from Alex's thought. Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive framework
On Thu, Aug 02, 2018 at 03:14:38AM +, Tian, Kevin wrote: > Date: Thu, 2 Aug 2018 03:14:38 + > From: "Tian, Kevin" > To: Kenneth Lee , Jonathan Corbet , > Herbert Xu , "David S . Miller" > , Joerg Roedel , Alex Williamson > , Kenneth Lee , Hao > Fang , Zhou Wang , Zaibo Xu > , Philippe Ombredanne , Greg > Kroah-Hartman , Thomas Gleixner > , "linux-...@vger.kernel.org" > , "linux-ker...@vger.kernel.org" > , "linux-cry...@vger.kernel.org" > , "iommu@lists.linux-foundation.org" > , "k...@vger.kernel.org" > , "linux-accelerat...@lists.ozlabs.org" > , Lu Baolu > , "Kumar, Sanjay K" > CC: "linux...@huawei.com" > Subject: RE: [RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive > framework > Message-ID: > > > > From: Kenneth Lee > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > From: Kenneth Lee > > > > WarpDrive is a common user space accelerator framework. Its main > > component > > in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It > > Not sure whether "share parent IOMMU" is a good term here. better > stick to what capabity you bring to user space, instead of describing > internal trick... Agree. The "SPI" is also strongly hint to "Share Peripheral Interrupt" or "Serial Peripheral Interface". Personally I hate this name. But I cannot find a better one. In the user space, we can use a impassible name (WarpDrive). But kernel require a name point to its feature... maybe I should use "Process-Shared Mdev" in next version? > > > exposes > > the hardware capabilities to the user space via vfio-mdev. So processes in > > user land can obtain a "queue" by open the device and direct access the > > hardware MMIO space or do DMA operation via VFIO interface. > > > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA patchset > > (it is still in RFC stage) to support multi-process. But This is not a must. > > Without the SVA patches, WarpDrive can still work for one process for > > every > > hardware device. > > > > This patch add detail documents for the framework. > > > > Signed-off-by: Kenneth Lee > > --- > > Documentation/00-INDEX| 2 + > > Documentation/warpdrive/warpdrive.rst | 153 ++ > > Documentation/warpdrive/wd-arch.svg | 732 > > ++ > > Documentation/warpdrive/wd.svg| 526 ++ > > 4 files changed, 1413 insertions(+) > > create mode 100644 Documentation/warpdrive/warpdrive.rst > > create mode 100644 Documentation/warpdrive/wd-arch.svg > > create mode 100644 Documentation/warpdrive/wd.svg > > > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX > > index 2754fe83f0d4..9959affab599 100644 > > --- a/Documentation/00-INDEX > > +++ b/Documentation/00-INDEX > > @@ -410,6 +410,8 @@ vm/ > > - directory with info on the Linux vm code. > > w1/ > > - directory with documents regarding the 1-wire (w1) subsystem. > > +warpdrive/ > > + - directory with documents about WarpDrive accelerator > > framework. > > watchdog/ > > - how to auto-reboot Linux if it has "fallen and can't get up". ;-) > > wimax/ > > diff --git a/Documentation/warpdrive/warpdrive.rst > > b/Documentation/warpdrive/warpdrive.rst > > new file mode 100644 > > index ..3792b2780ea6 > > --- /dev/null > > +++ b/Documentation/warpdrive/warpdrive.rst > > @@ -0,0 +1,153 @@ > > +Introduction of WarpDrive > > += > > + > > +*WarpDrive* is a general accelerator framework built on top of vfio. > > +It can be taken as a light weight virtual function, which you can use > > without > > +*SR-IOV* like facility and can be shared among multiple processes. > > + > > +It can be used as the quick channel for accelerators, network adaptors or > > +other hardware in user space. It can make some implementation simpler. > > E.g. > > +you can reuse most of the *netdev* driver and just share some ring buffer > > to > > +the user space driver for *DPDK* or *ODP*. Or you can combine the RSA > > +accelerator with the *netdev* in the user space as a Web reversed proxy, > > etc. > > + > > +The name *WarpDrive* is simply a cool and general name meaning the > > framework > > +makes the application faster. In kernel, the framework is called SPIMDEV, > > +namely "Share Parent IOMMU Mediated Device". > > + > > + > > +How does it work > > + > > + > > +*WarpDrive* takes the Hardware Accelerator as a heterogeneous > > processor which > > +can share some load for the CPU: > > + > > +.. image:: wd.svg > > +:alt: This is a .svg image, if your browser cannot show it, > > +try to download and view it locally > > + > > +So it provides the capability to the user application to: > > + > > +1. Send request to the hardware > > +2. Share memory with the application and other accelerators > > + > > +These requirements can be fulfilled by VFIO if the accelerator can serve > > each > > +application with a separated Virtual Function. But a *SR-IOV* like VF
Re: [RFC PATCH 2/7] iommu: Add share domain interface in iommu for spimdev
On Thu, Aug 02, 2018 at 03:17:03AM +, Tian, Kevin wrote:
> Date: Thu, 2 Aug 2018 03:17:03 +
> From: "Tian, Kevin"
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe Ombredanne , Greg
> Kroah-Hartman , Thomas Gleixner
> , "linux-...@vger.kernel.org"
> , "linux-ker...@vger.kernel.org"
> , "linux-cry...@vger.kernel.org"
> , "iommu@lists.linux-foundation.org"
> , "k...@vger.kernel.org"
> , "linux-accelerat...@lists.ozlabs.org"
> , Lu Baolu
> , "Kumar, Sanjay K"
> CC: "linux...@huawei.com"
> Subject: RE: [RFC PATCH 2/7] iommu: Add share domain interface in iommu for
> spimdev
> Message-ID:
>
>
> > From: Kenneth Lee
> > Sent: Wednesday, August 1, 2018 6:22 PM
> >
> > From: Kenneth Lee
> >
> > This patch add sharing interface for a iommu_group. The new interface:
> >
> > iommu_group_share_domain()
> > iommu_group_unshare_domain()
> >
> > can be used by some virtual iommu_group (such as iommu_group for
> > spimdev)
> > to share their parent's iommu_group.
> >
> > When the domain of the group is shared, it cannot be changed before
> > unshared. In the future, notification can be added if update is required.
>
> Is it necessary or just asking VFIO to use parent domain directly?
>
Even we add to VFIO, the iommu still need to be changed. We can move the type1
part to VFIO if we have agreement in RFC stage.
> >
> > Signed-off-by: Kenneth Lee
> > ---
> > drivers/iommu/iommu.c | 28 +++-
> > include/linux/iommu.h | 2 ++
> > 2 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 63b37563db7e..a832aafe660d 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -54,6 +54,9 @@ struct iommu_group {
> > int id;
> > struct iommu_domain *default_domain;
> > struct iommu_domain *domain;
> > + atomic_t domain_shared_ref; /* Number of user of current domain.
> > +* The domain cannot be modified if ref >
> > 0
> > +*/
> > };
> >
> > struct group_device {
> > @@ -353,6 +356,7 @@ struct iommu_group *iommu_group_alloc(void)
> > return ERR_PTR(ret);
> > }
> > group->id = ret;
> > + atomic_set(>domain_shared_ref, 0);
> >
> > ret = kobject_init_and_add(>kobj, _group_ktype,
> >NULL, "%d", group->id);
> > @@ -482,6 +486,25 @@ int iommu_group_set_name(struct iommu_group
> > *group, const char *name)
> > }
> > EXPORT_SYMBOL_GPL(iommu_group_set_name);
> >
> > +struct iommu_domain *iommu_group_share_domain(struct
> > iommu_group *group)
> > +{
> > + /* the domain can be shared only when the default domain is used
> > */
> > + /* todo: more shareable check */
> > + if (group->domain != group->default_domain)
> > + return ERR_PTR(-EINVAL);
> > +
> > + atomic_inc(>domain_shared_ref);
> > + return group->domain;
> > +}
> > +EXPORT_SYMBOL_GPL(iommu_group_share_domain);
> > +
> > +void iommu_group_unshare_domain(struct iommu_group *group)
> > +{
> > + atomic_dec(>domain_shared_ref);
> > + WARN_ON(atomic_read(>domain_shared_ref) < 0);
> > +}
> > +EXPORT_SYMBOL_GPL(iommu_group_unshare_domain);
> > +
> > static int iommu_group_create_direct_mappings(struct iommu_group
> > *group,
> > struct device *dev)
> > {
> > @@ -1401,7 +1424,8 @@ static int __iommu_attach_group(struct
> > iommu_domain *domain,
> > {
> > int ret;
> >
> > - if (group->default_domain && group->domain != group-
> > >default_domain)
> > + if ((group->default_domain && group->domain != group-
> > >default_domain) ||
> > +atomic_read(>domain_shared_ref) > 0)
> > return -EBUSY;
> >
> > ret = __iommu_group_for_each_dev(group, domain,
> > @@ -1438,6 +1462,8 @@ static void __iommu_detach_group(struct
> > iommu_domain *domain,
> > {
> > int ret;
> >
> > + WARN_ON(atomic_read(>domain_shared_ref) > 0);
> > +
> > if (!group->default_domain) {
> > __iommu_group_for_each_dev(group, domain,
> >iommu_group_do_detach_device);
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 19938ee6eb31..278d60e3ec39 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -349,6 +349,8 @@ extern int iommu_domain_get_attr(struct
> > iommu_domain *domain, enum iommu_attr,
> > void *data);
> > extern int iommu_domain_set_attr(struct iommu_domain *domain, enum
> > iommu_attr,
> > void *data);
> > +extern struct iommu_domain *iommu_group_share_domain(struct
> > iommu_group *group);
> > +extern void iommu_group_unshare_domain(struct iommu_group *group);
> >
> > /* Window handling function prototypes */
> > extern int
Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
On Thu, Aug 02, 2018 at 02:33:12AM +, Tian, Kevin wrote: > Date: Thu, 2 Aug 2018 02:33:12 + > From: "Tian, Kevin" > To: Jerome Glisse , Kenneth Lee > CC: Hao Fang , Herbert Xu > , "k...@vger.kernel.org" > , Jonathan Corbet , Greg > Kroah-Hartman , "linux-...@vger.kernel.org" > , "Kumar, Sanjay K" , > "iommu@lists.linux-foundation.org" , > "linux-ker...@vger.kernel.org" , > "linux...@huawei.com" , Alex Williamson > , Thomas Gleixner , > "linux-cry...@vger.kernel.org" , Philippe > Ombredanne , Zaibo Xu , Kenneth > Lee , "David S . Miller" , > "linux-accelerat...@lists.ozlabs.org" > > Subject: RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive > Message-ID: > > > > From: Jerome Glisse > > Sent: Thursday, August 2, 2018 12:57 AM > > > > On Wed, Aug 01, 2018 at 06:22:14PM +0800, Kenneth Lee wrote: > > > From: Kenneth Lee > > > > > > WarpDrive is an accelerator framework to expose the hardware > > capabilities > > > directly to the user space. It makes use of the exist vfio and vfio-mdev > > > facilities. So the user application can send request and DMA to the > > > hardware without interaction with the kernel. This remove the latency > > > of syscall and context switch. > > > > > > The patchset contains documents for the detail. Please refer to it for > > more > > > information. > > > > > > This patchset is intended to be used with Jean Philippe Brucker's SVA > > > patch [1] (Which is also in RFC stage). But it is not mandatory. This > > > patchset is tested in the latest mainline kernel without the SVA patches. > > > So it support only one process for each accelerator. > > > > > > With SVA support, WarpDrive can support multi-process in the same > > > accelerator device. We tested it in our SoC integrated Accelerator (board > > > ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. > > > > I have not fully inspected things nor do i know enough about > > this Hisilicon ZIP accelerator to ascertain, but from glimpsing > > at the code it seems that it is unsafe to use even with SVA due > > to the doorbell. There is a comment talking about safetyness > > in patch 7. > > > > Exposing thing to userspace is always enticing, but if it is > > a security risk then it should clearly say so and maybe a > > kernel boot flag should be necessary to allow such device to > > be use. > > But doorbell is just a notification. Except for DOS (to make hardware busy) it cannot actually take or change anything from the kernel space. And the DOS problem can be always taken as the problem that a group of processes share the same kernel entity. In the coming HIP09 hardware, the doorbell will come with a random number so only the process who allocated the queue can knock it correctly. > > > > My more general question is do we want to grow VFIO to become > > a more generic device driver API. This patchset adds a command > > queue concept to it (i don't think it exist today but i have > > not follow VFIO closely). > > The thing is, VFIO is the only place to support DMA from user land. If we don't put it here, we have to create another similar facility to support the same. > > Why is that any better that existing driver model ? Where a > > device create a device file (can be character device, block > > device, ...). Such models also allow for direct hardware > > access from userspace. For instance see the AMD KFD driver > > inside drivers/gpu/drm/amd > > One motivation I guess, is that most accelerators lack of a > well-abstracted high level APIs similar to GPU side (e.g. OpenCL > clearly defines Shared Virtual Memory models). VFIO mdev > might be an alternative common interface to enable SVA usages > on various accelerators... > Yes. > > > > So you can already do what you are doing with the Hisilicon > > driver today without this new infrastructure. This only need > > hardware that have command queue and doorbell like mechanisms. > > > > > > Unlike mdev which unify a very high level concept, it seems > > to me spimdev just introduce low level concept (namely command > > queue) and i don't see the intrinsic value here. > > As I have said, VFIO is the only place support DMA from user space now. > > > > Cheers, > > Jérôme > > ___ > > iommu mailing list > > iommu@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- -Kenneth(Hisilicon) 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the
Re: [RFC PATCH 3/7] vfio: add spimdev support
On Thu, Aug 02, 2018 at 03:21:25AM +, Tian, Kevin wrote:
> Date: Thu, 2 Aug 2018 03:21:25 +
> From: "Tian, Kevin"
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe Ombredanne , Greg
> Kroah-Hartman , Thomas Gleixner
> , "linux-...@vger.kernel.org"
> , "linux-ker...@vger.kernel.org"
> , "linux-cry...@vger.kernel.org"
> , "iommu@lists.linux-foundation.org"
> , "k...@vger.kernel.org"
> , "linux-accelerat...@lists.ozlabs.org"
> , Lu Baolu
> , "Kumar, Sanjay K"
> CC: "linux...@huawei.com"
> Subject: RE: [RFC PATCH 3/7] vfio: add spimdev support
> Message-ID:
>
>
> > From: Kenneth Lee
> > Sent: Wednesday, August 1, 2018 6:22 PM
> >
> > From: Kenneth Lee
> >
> > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from
> > the general vfio-mdev:
> >
> > 1. It shares its parent's IOMMU.
> > 2. There is no hardware resource attached to the mdev is created. The
> > hardware resource (A `queue') is allocated only when the mdev is
> > opened.
>
> Alex has concern on doing so, as pointed out in:
>
> https://www.spinics.net/lists/kvm/msg172652.html
>
> resource allocation should be reserved at creation time.
Yes. That is why I keep telling that SPIMDEV is not for "VM", it is for "many
processes", it is just an access point to the process. Not a device to VM. I
hope
Alex can accept it:)
>
> >
> > Currently only the vfio type-1 driver is updated to make it to be aware
> > of.
> >
> > Signed-off-by: Kenneth Lee
> > Signed-off-by: Zaibo Xu
> > Signed-off-by: Zhou Wang
> > ---
> > drivers/vfio/Kconfig| 1 +
> > drivers/vfio/Makefile | 1 +
> > drivers/vfio/spimdev/Kconfig| 10 +
> > drivers/vfio/spimdev/Makefile | 3 +
> > drivers/vfio/spimdev/vfio_spimdev.c | 421
> >
> > drivers/vfio/vfio_iommu_type1.c | 136 -
> > include/linux/vfio_spimdev.h| 95 +++
> > include/uapi/linux/vfio_spimdev.h | 28 ++
> > 8 files changed, 689 insertions(+), 6 deletions(-)
> > create mode 100644 drivers/vfio/spimdev/Kconfig
> > create mode 100644 drivers/vfio/spimdev/Makefile
> > create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c
> > create mode 100644 include/linux/vfio_spimdev.h
> > create mode 100644 include/uapi/linux/vfio_spimdev.h
> >
> > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> > index c84333eb5eb5..3719eba72ef1 100644
> > --- a/drivers/vfio/Kconfig
> > +++ b/drivers/vfio/Kconfig
> > @@ -47,4 +47,5 @@ menuconfig VFIO_NOIOMMU
> > source "drivers/vfio/pci/Kconfig"
> > source "drivers/vfio/platform/Kconfig"
> > source "drivers/vfio/mdev/Kconfig"
> > +source "drivers/vfio/spimdev/Kconfig"
> > source "virt/lib/Kconfig"
> > diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> > index de67c4725cce..28f3ef0cdce1 100644
> > --- a/drivers/vfio/Makefile
> > +++ b/drivers/vfio/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
> > obj-$(CONFIG_VFIO_PCI) += pci/
> > obj-$(CONFIG_VFIO_PLATFORM) += platform/
> > obj-$(CONFIG_VFIO_MDEV) += mdev/
> > +obj-$(CONFIG_VFIO_SPIMDEV) += spimdev/
> > diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig
> > new file mode 100644
> > index ..1226301f9d0e
> > --- /dev/null
> > +++ b/drivers/vfio/spimdev/Kconfig
> > @@ -0,0 +1,10 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +config VFIO_SPIMDEV
> > + tristate "Support for Share Parent IOMMU MDEV"
> > + depends on VFIO_MDEV_DEVICE
> > + help
> > + Support for VFIO Share Parent IOMMU MDEV, which enable the
> > kernel to
> > + support for the light weight hardware accelerator framework,
> > WrapDrive.
> > +
> > + To compile this as a module, choose M here: the module will be
> > called
> > + spimdev.
> > diff --git a/drivers/vfio/spimdev/Makefile b/drivers/vfio/spimdev/Makefile
> > new file mode 100644
> > index ..d02fb69c37e4
> > --- /dev/null
> > +++ b/drivers/vfio/spimdev/Makefile
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +spimdev-y := spimdev.o
> > +obj-$(CONFIG_VFIO_SPIMDEV) += vfio_spimdev.o
> > diff --git a/drivers/vfio/spimdev/vfio_spimdev.c
> > b/drivers/vfio/spimdev/vfio_spimdev.c
> > new file mode 100644
> > index ..1b6910c9d27d
> > --- /dev/null
> > +++ b/drivers/vfio/spimdev/vfio_spimdev.c
> > @@ -0,0 +1,421 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct spimdev_mdev_state {
> > + struct vfio_spimdev *spimdev;
> > +};
> > +
> > +static struct class *spimdev_class;
> > +static DEFINE_IDR(spimdev_idr);
> > +
> > +static int vfio_spimdev_dev_exist(struct device *dev, void *data)
> > +{
> > + return !strcmp(dev_name(dev), dev_name((struct device *)data));
> > +}
> > +
> > +#ifdef CONFIG_IOMMU_SVA
> >
Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
On Thu, Aug 02, 2018 at 02:59:33AM +, Tian, Kevin wrote: > Date: Thu, 2 Aug 2018 02:59:33 + > From: "Tian, Kevin" > To: Kenneth Lee , Jonathan Corbet , > Herbert Xu , "David S . Miller" > , Joerg Roedel , Alex Williamson > , Kenneth Lee , Hao > Fang , Zhou Wang , Zaibo Xu > , Philippe Ombredanne , Greg > Kroah-Hartman , Thomas Gleixner > , "linux-...@vger.kernel.org" > , "linux-ker...@vger.kernel.org" > , "linux-cry...@vger.kernel.org" > , "iommu@lists.linux-foundation.org" > , "k...@vger.kernel.org" > , "linux-accelerat...@lists.ozlabs.org" > , Lu Baolu > , "Kumar, Sanjay K" > CC: "linux...@huawei.com" > Subject: RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive > Message-ID: > > > > From: Kenneth Lee > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > From: Kenneth Lee > > > > WarpDrive is an accelerator framework to expose the hardware capabilities > > directly to the user space. It makes use of the exist vfio and vfio-mdev > > facilities. So the user application can send request and DMA to the > > hardware without interaction with the kernel. This remove the latency > > of syscall and context switch. > > > > The patchset contains documents for the detail. Please refer to it for more > > information. > > > > This patchset is intended to be used with Jean Philippe Brucker's SVA > > patch [1] (Which is also in RFC stage). But it is not mandatory. This > > patchset is tested in the latest mainline kernel without the SVA patches. > > So it support only one process for each accelerator. > > If no sharing, then why not just assigning the whole parent device to > the process? IMO if SVA usage is the clear goal of your series, it > might be made clearly so then Jean's series is mandatory dependency... > We don't know how SVA will be finally. But the feature, "make use of per-PASID/substream ID IOMMU page table", should be able to be enabled in the kernel. So we don't want to enforce it here. After we have this serial ready, it can be hooked to any implementation. Further more, even without "per-PASID IOMMU page table", this series has its value. It is not simply dedicate the whole device to the process. It "shares" the device with the kernel driver. So you can support crypto and a user application at the same time. > > > > With SVA support, WarpDrive can support multi-process in the same > > accelerator device. We tested it in our SoC integrated Accelerator (board > > ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. > > > > We have noticed the IOMMU aware mdev RFC announced recently [3]. > > > > The IOMMU aware mdev has similar idea but different intention comparing > > to > > WarpDrive. It intends to dedicate part of the hardware resource to a VM. > > Not just to VM, though I/O Virtualization is in the name. You can assign > such mdev to either VMs, containers, or bare metal processes. It's just > a fully-isolated device from user space p.o.v. Oh, yes. Thank you for clarification. > > > And the design is supposed to be used with Scalable I/O Virtualization. > > While spimdev is intended to share the hardware resource with a big > > amount > > of processes. It just requires the hardware supporting address > > translation per process (PCIE's PASID or ARM SMMU's substream ID). > > > > But we don't see serious confliction on both design. We believe they can be > > normalized as one. > > yes there are something which can be shared, e.g. regarding to > the interface to IOMMU. > > Conceptually I see them different mindset on device resource sharing: > > WarpDrive more aims to provide a generic framework to enable SVA > usages on various accelerators, which lack of a well-abstracted user > API like OpenCL. SVA is a hardware capability - sort of exposing resources > composing ONE capability to user space through mdev framework. It is > not like a VF which naturally carries most capabilities as PF. > Yes. But we believe the user abstraction layer will be enabled soon when the channel is opened. WarpDrive gives the hardware the chance to serve the application directly. For example, an AI engine can be called by many processes for inference. The resource need not to be dedicated to one particular process. > Intel Scalable I/O virtualization is a thorough design to partition the > device into minimal sharable copies (queue, queue pair, context), > while each copy carries most PF capabilities (including SVA) similar to > VF. Also with IOMMU scalable mode support, the copy can be > independently assigned to any client (process, container, VM, etc.) > Yes, we can see this intension. > Thanks > Kevin Thank you. -- -Kenneth(Hisilicon) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 3/7] vfio: add spimdev support
> From: Kenneth Lee
> Sent: Wednesday, August 1, 2018 6:22 PM
>
> From: Kenneth Lee
>
> SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from
> the general vfio-mdev:
>
> 1. It shares its parent's IOMMU.
> 2. There is no hardware resource attached to the mdev is created. The
> hardware resource (A `queue') is allocated only when the mdev is
> opened.
Alex has concern on doing so, as pointed out in:
https://www.spinics.net/lists/kvm/msg172652.html
resource allocation should be reserved at creation time.
>
> Currently only the vfio type-1 driver is updated to make it to be aware
> of.
>
> Signed-off-by: Kenneth Lee
> Signed-off-by: Zaibo Xu
> Signed-off-by: Zhou Wang
> ---
> drivers/vfio/Kconfig| 1 +
> drivers/vfio/Makefile | 1 +
> drivers/vfio/spimdev/Kconfig| 10 +
> drivers/vfio/spimdev/Makefile | 3 +
> drivers/vfio/spimdev/vfio_spimdev.c | 421
>
> drivers/vfio/vfio_iommu_type1.c | 136 -
> include/linux/vfio_spimdev.h| 95 +++
> include/uapi/linux/vfio_spimdev.h | 28 ++
> 8 files changed, 689 insertions(+), 6 deletions(-)
> create mode 100644 drivers/vfio/spimdev/Kconfig
> create mode 100644 drivers/vfio/spimdev/Makefile
> create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c
> create mode 100644 include/linux/vfio_spimdev.h
> create mode 100644 include/uapi/linux/vfio_spimdev.h
>
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index c84333eb5eb5..3719eba72ef1 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -47,4 +47,5 @@ menuconfig VFIO_NOIOMMU
> source "drivers/vfio/pci/Kconfig"
> source "drivers/vfio/platform/Kconfig"
> source "drivers/vfio/mdev/Kconfig"
> +source "drivers/vfio/spimdev/Kconfig"
> source "virt/lib/Kconfig"
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index de67c4725cce..28f3ef0cdce1 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
> obj-$(CONFIG_VFIO_PCI) += pci/
> obj-$(CONFIG_VFIO_PLATFORM) += platform/
> obj-$(CONFIG_VFIO_MDEV) += mdev/
> +obj-$(CONFIG_VFIO_SPIMDEV) += spimdev/
> diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig
> new file mode 100644
> index ..1226301f9d0e
> --- /dev/null
> +++ b/drivers/vfio/spimdev/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config VFIO_SPIMDEV
> + tristate "Support for Share Parent IOMMU MDEV"
> + depends on VFIO_MDEV_DEVICE
> + help
> + Support for VFIO Share Parent IOMMU MDEV, which enable the
> kernel to
> + support for the light weight hardware accelerator framework,
> WrapDrive.
> +
> + To compile this as a module, choose M here: the module will be
> called
> + spimdev.
> diff --git a/drivers/vfio/spimdev/Makefile b/drivers/vfio/spimdev/Makefile
> new file mode 100644
> index ..d02fb69c37e4
> --- /dev/null
> +++ b/drivers/vfio/spimdev/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +spimdev-y := spimdev.o
> +obj-$(CONFIG_VFIO_SPIMDEV) += vfio_spimdev.o
> diff --git a/drivers/vfio/spimdev/vfio_spimdev.c
> b/drivers/vfio/spimdev/vfio_spimdev.c
> new file mode 100644
> index ..1b6910c9d27d
> --- /dev/null
> +++ b/drivers/vfio/spimdev/vfio_spimdev.c
> @@ -0,0 +1,421 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct spimdev_mdev_state {
> + struct vfio_spimdev *spimdev;
> +};
> +
> +static struct class *spimdev_class;
> +static DEFINE_IDR(spimdev_idr);
> +
> +static int vfio_spimdev_dev_exist(struct device *dev, void *data)
> +{
> + return !strcmp(dev_name(dev), dev_name((struct device *)data));
> +}
> +
> +#ifdef CONFIG_IOMMU_SVA
> +static bool vfio_spimdev_is_valid_pasid(int pasid)
> +{
> + struct mm_struct *mm;
> +
> + mm = iommu_sva_find(pasid);
> + if (mm) {
> + mmput(mm);
> + return mm == current->mm;
> + }
> +
> + return false;
> +}
> +#endif
> +
> +/* Check if the device is a mediated device belongs to vfio_spimdev */
> +int vfio_spimdev_is_spimdev(struct device *dev)
> +{
> + struct mdev_device *mdev;
> + struct device *pdev;
> +
> + mdev = mdev_from_dev(dev);
> + if (!mdev)
> + return 0;
> +
> + pdev = mdev_parent_dev(mdev);
> + if (!pdev)
> + return 0;
> +
> + return class_for_each_device(spimdev_class, NULL, pdev,
> + vfio_spimdev_dev_exist);
> +}
> +EXPORT_SYMBOL_GPL(vfio_spimdev_is_spimdev);
> +
> +struct vfio_spimdev *vfio_spimdev_pdev_spimdev(struct device *dev)
> +{
> + struct device *class_dev;
> +
> + if (!dev)
> + return ERR_PTR(-EINVAL);
> +
> + class_dev = class_find_device(spimdev_class, NULL, dev,
> + (int(*)(struct device *, const void
>
RE: [RFC PATCH 2/7] iommu: Add share domain interface in iommu for spimdev
> From: Kenneth Lee
> Sent: Wednesday, August 1, 2018 6:22 PM
>
> From: Kenneth Lee
>
> This patch add sharing interface for a iommu_group. The new interface:
>
> iommu_group_share_domain()
> iommu_group_unshare_domain()
>
> can be used by some virtual iommu_group (such as iommu_group for
> spimdev)
> to share their parent's iommu_group.
>
> When the domain of the group is shared, it cannot be changed before
> unshared. In the future, notification can be added if update is required.
Is it necessary or just asking VFIO to use parent domain directly?
>
> Signed-off-by: Kenneth Lee
> ---
> drivers/iommu/iommu.c | 28 +++-
> include/linux/iommu.h | 2 ++
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 63b37563db7e..a832aafe660d 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -54,6 +54,9 @@ struct iommu_group {
> int id;
> struct iommu_domain *default_domain;
> struct iommu_domain *domain;
> + atomic_t domain_shared_ref; /* Number of user of current domain.
> + * The domain cannot be modified if ref >
> 0
> + */
> };
>
> struct group_device {
> @@ -353,6 +356,7 @@ struct iommu_group *iommu_group_alloc(void)
> return ERR_PTR(ret);
> }
> group->id = ret;
> + atomic_set(>domain_shared_ref, 0);
>
> ret = kobject_init_and_add(>kobj, _group_ktype,
> NULL, "%d", group->id);
> @@ -482,6 +486,25 @@ int iommu_group_set_name(struct iommu_group
> *group, const char *name)
> }
> EXPORT_SYMBOL_GPL(iommu_group_set_name);
>
> +struct iommu_domain *iommu_group_share_domain(struct
> iommu_group *group)
> +{
> + /* the domain can be shared only when the default domain is used
> */
> + /* todo: more shareable check */
> + if (group->domain != group->default_domain)
> + return ERR_PTR(-EINVAL);
> +
> + atomic_inc(>domain_shared_ref);
> + return group->domain;
> +}
> +EXPORT_SYMBOL_GPL(iommu_group_share_domain);
> +
> +void iommu_group_unshare_domain(struct iommu_group *group)
> +{
> + atomic_dec(>domain_shared_ref);
> + WARN_ON(atomic_read(>domain_shared_ref) < 0);
> +}
> +EXPORT_SYMBOL_GPL(iommu_group_unshare_domain);
> +
> static int iommu_group_create_direct_mappings(struct iommu_group
> *group,
> struct device *dev)
> {
> @@ -1401,7 +1424,8 @@ static int __iommu_attach_group(struct
> iommu_domain *domain,
> {
> int ret;
>
> - if (group->default_domain && group->domain != group-
> >default_domain)
> + if ((group->default_domain && group->domain != group-
> >default_domain) ||
> + atomic_read(>domain_shared_ref) > 0)
> return -EBUSY;
>
> ret = __iommu_group_for_each_dev(group, domain,
> @@ -1438,6 +1462,8 @@ static void __iommu_detach_group(struct
> iommu_domain *domain,
> {
> int ret;
>
> + WARN_ON(atomic_read(>domain_shared_ref) > 0);
> +
> if (!group->default_domain) {
> __iommu_group_for_each_dev(group, domain,
> iommu_group_do_detach_device);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 19938ee6eb31..278d60e3ec39 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -349,6 +349,8 @@ extern int iommu_domain_get_attr(struct
> iommu_domain *domain, enum iommu_attr,
>void *data);
> extern int iommu_domain_set_attr(struct iommu_domain *domain, enum
> iommu_attr,
>void *data);
> +extern struct iommu_domain *iommu_group_share_domain(struct
> iommu_group *group);
> +extern void iommu_group_unshare_domain(struct iommu_group *group);
>
> /* Window handling function prototypes */
> extern int iommu_domain_window_enable(struct iommu_domain
> *domain, u32 wnd_nr,
> --
> 2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive framework
> From: Kenneth Lee > Sent: Wednesday, August 1, 2018 6:22 PM > > From: Kenneth Lee > > WarpDrive is a common user space accelerator framework. Its main > component > in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It Not sure whether "share parent IOMMU" is a good term here. better stick to what capabity you bring to user space, instead of describing internal trick... > exposes > the hardware capabilities to the user space via vfio-mdev. So processes in > user land can obtain a "queue" by open the device and direct access the > hardware MMIO space or do DMA operation via VFIO interface. > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA patchset > (it is still in RFC stage) to support multi-process. But This is not a must. > Without the SVA patches, WarpDrive can still work for one process for > every > hardware device. > > This patch add detail documents for the framework. > > Signed-off-by: Kenneth Lee > --- > Documentation/00-INDEX| 2 + > Documentation/warpdrive/warpdrive.rst | 153 ++ > Documentation/warpdrive/wd-arch.svg | 732 > ++ > Documentation/warpdrive/wd.svg| 526 ++ > 4 files changed, 1413 insertions(+) > create mode 100644 Documentation/warpdrive/warpdrive.rst > create mode 100644 Documentation/warpdrive/wd-arch.svg > create mode 100644 Documentation/warpdrive/wd.svg > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX > index 2754fe83f0d4..9959affab599 100644 > --- a/Documentation/00-INDEX > +++ b/Documentation/00-INDEX > @@ -410,6 +410,8 @@ vm/ > - directory with info on the Linux vm code. > w1/ > - directory with documents regarding the 1-wire (w1) subsystem. > +warpdrive/ > + - directory with documents about WarpDrive accelerator > framework. > watchdog/ > - how to auto-reboot Linux if it has "fallen and can't get up". ;-) > wimax/ > diff --git a/Documentation/warpdrive/warpdrive.rst > b/Documentation/warpdrive/warpdrive.rst > new file mode 100644 > index ..3792b2780ea6 > --- /dev/null > +++ b/Documentation/warpdrive/warpdrive.rst > @@ -0,0 +1,153 @@ > +Introduction of WarpDrive > += > + > +*WarpDrive* is a general accelerator framework built on top of vfio. > +It can be taken as a light weight virtual function, which you can use > without > +*SR-IOV* like facility and can be shared among multiple processes. > + > +It can be used as the quick channel for accelerators, network adaptors or > +other hardware in user space. It can make some implementation simpler. > E.g. > +you can reuse most of the *netdev* driver and just share some ring buffer > to > +the user space driver for *DPDK* or *ODP*. Or you can combine the RSA > +accelerator with the *netdev* in the user space as a Web reversed proxy, > etc. > + > +The name *WarpDrive* is simply a cool and general name meaning the > framework > +makes the application faster. In kernel, the framework is called SPIMDEV, > +namely "Share Parent IOMMU Mediated Device". > + > + > +How does it work > + > + > +*WarpDrive* takes the Hardware Accelerator as a heterogeneous > processor which > +can share some load for the CPU: > + > +.. image:: wd.svg > +:alt: This is a .svg image, if your browser cannot show it, > +try to download and view it locally > + > +So it provides the capability to the user application to: > + > +1. Send request to the hardware > +2. Share memory with the application and other accelerators > + > +These requirements can be fulfilled by VFIO if the accelerator can serve > each > +application with a separated Virtual Function. But a *SR-IOV* like VF (we > will > +call it *HVF* hereinafter) design is too heavy for the accelerator which > +service thousands of processes. > + > +And the *HVF* is not good for the scenario that a device keep most of its > +resource but share partial of the function to the user space. E.g. a *NIC* > +works as a *netdev* but share some hardware queues to the user > application to > +send packets direct to the hardware. > + > +*VFIO-mdev* can solve some of the problem here. But *VFIO-mdev* has > two problem: > + > +1. it cannot make use of its parent device's IOMMU. > +2. it is assumed to be openned only once. > + > +So it will need some add-on for better resource control and let the VFIO > +driver be aware of this. > + > + > +Architecture > + > + > +The full *WarpDrive* architecture is represented in the following class > +diagram: > + > +.. image:: wd-arch.svg > +:alt: This is a .svg image, if your browser cannot show it, > +try to download and view it locally > + > +The idea is: when a device is probed, it can be registered to the general > +framework, e.g. *netdev* or *crypto*, and the *SPIMDEV* at the same > time. > + > +If *SPIMDEV* is registered. A *mdev* creation interface is created. Then > the > +system administrator can create
Re: [RFC PATCH 3/7] vfio: add spimdev support
On Wed, Aug 01, 2018 at 09:23:52AM -0700, Randy Dunlap wrote: > Date: Wed, 1 Aug 2018 09:23:52 -0700 > From: Randy Dunlap > To: Kenneth Lee , Jonathan Corbet , > Herbert Xu , "David S . Miller" > , Joerg Roedel , Alex Williamson > , Kenneth Lee , Hao > Fang , Zhou Wang , Zaibo Xu > , Philippe Ombredanne , Greg > Kroah-Hartman , Thomas Gleixner > , linux-...@vger.kernel.org, > linux-ker...@vger.kernel.org, linux-cry...@vger.kernel.org, > iommu@lists.linux-foundation.org, k...@vger.kernel.org, > linux-accelerat...@lists.ozlabs.org, Lu Baolu , > Sanjay Kumar > CC: linux...@huawei.com > Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Thunderbird/52.9.1 > Message-ID: > > On 08/01/2018 03:22 AM, Kenneth Lee wrote: > > From: Kenneth Lee > > > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from > > the general vfio-mdev: > > > > 1. It shares its parent's IOMMU. > > 2. There is no hardware resource attached to the mdev is created. The > > hardware resource (A `queue') is allocated only when the mdev is > > opened. > > > > Currently only the vfio type-1 driver is updated to make it to be aware > > of. > > > > Signed-off-by: Kenneth Lee > > Signed-off-by: Zaibo Xu > > Signed-off-by: Zhou Wang > > --- > > drivers/vfio/Kconfig| 1 + > > drivers/vfio/Makefile | 1 + > > drivers/vfio/spimdev/Kconfig| 10 + > > drivers/vfio/spimdev/Makefile | 3 + > > drivers/vfio/spimdev/vfio_spimdev.c | 421 > > drivers/vfio/vfio_iommu_type1.c | 136 - > > include/linux/vfio_spimdev.h| 95 +++ > > include/uapi/linux/vfio_spimdev.h | 28 ++ > > 8 files changed, 689 insertions(+), 6 deletions(-) > > create mode 100644 drivers/vfio/spimdev/Kconfig > > create mode 100644 drivers/vfio/spimdev/Makefile > > create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c > > create mode 100644 include/linux/vfio_spimdev.h > > create mode 100644 include/uapi/linux/vfio_spimdev.h > > > > diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig > > new file mode 100644 > > index ..1226301f9d0e > > --- /dev/null > > +++ b/drivers/vfio/spimdev/Kconfig > > @@ -0,0 +1,10 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +config VFIO_SPIMDEV > > + tristate "Support for Share Parent IOMMU MDEV" > > + depends on VFIO_MDEV_DEVICE > > + help > > + Support for VFIO Share Parent IOMMU MDEV, which enable the kernel to > > enables > > > + support for the light weight hardware accelerator framework, > > WrapDrive. > > support the lightweight hardware accelerator framework, WrapDrive. > > > + > > + To compile this as a module, choose M here: the module will be called > > + spimdev. > > > -- > ~Randy Thanks, I will update it in next version. -- -Kenneth(Hisilicon) 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
> From: Kenneth Lee > Sent: Wednesday, August 1, 2018 6:22 PM > > From: Kenneth Lee > > WarpDrive is an accelerator framework to expose the hardware capabilities > directly to the user space. It makes use of the exist vfio and vfio-mdev > facilities. So the user application can send request and DMA to the > hardware without interaction with the kernel. This remove the latency > of syscall and context switch. > > The patchset contains documents for the detail. Please refer to it for more > information. > > This patchset is intended to be used with Jean Philippe Brucker's SVA > patch [1] (Which is also in RFC stage). But it is not mandatory. This > patchset is tested in the latest mainline kernel without the SVA patches. > So it support only one process for each accelerator. If no sharing, then why not just assigning the whole parent device to the process? IMO if SVA usage is the clear goal of your series, it might be made clearly so then Jean's series is mandatory dependency... > > With SVA support, WarpDrive can support multi-process in the same > accelerator device. We tested it in our SoC integrated Accelerator (board > ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. > > We have noticed the IOMMU aware mdev RFC announced recently [3]. > > The IOMMU aware mdev has similar idea but different intention comparing > to > WarpDrive. It intends to dedicate part of the hardware resource to a VM. Not just to VM, though I/O Virtualization is in the name. You can assign such mdev to either VMs, containers, or bare metal processes. It's just a fully-isolated device from user space p.o.v. > And the design is supposed to be used with Scalable I/O Virtualization. > While spimdev is intended to share the hardware resource with a big > amount > of processes. It just requires the hardware supporting address > translation per process (PCIE's PASID or ARM SMMU's substream ID). > > But we don't see serious confliction on both design. We believe they can be > normalized as one. yes there are something which can be shared, e.g. regarding to the interface to IOMMU. Conceptually I see them different mindset on device resource sharing: WarpDrive more aims to provide a generic framework to enable SVA usages on various accelerators, which lack of a well-abstracted user API like OpenCL. SVA is a hardware capability - sort of exposing resources composing ONE capability to user space through mdev framework. It is not like a VF which naturally carries most capabilities as PF. Intel Scalable I/O virtualization is a thorough design to partition the device into minimal sharable copies (queue, queue pair, context), while each copy carries most PF capabilities (including SVA) similar to VF. Also with IOMMU scalable mode support, the copy can be independently assigned to any client (process, container, VM, etc.) Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
> From: Jerome Glisse > Sent: Thursday, August 2, 2018 12:57 AM > > On Wed, Aug 01, 2018 at 06:22:14PM +0800, Kenneth Lee wrote: > > From: Kenneth Lee > > > > WarpDrive is an accelerator framework to expose the hardware > capabilities > > directly to the user space. It makes use of the exist vfio and vfio-mdev > > facilities. So the user application can send request and DMA to the > > hardware without interaction with the kernel. This remove the latency > > of syscall and context switch. > > > > The patchset contains documents for the detail. Please refer to it for > more > > information. > > > > This patchset is intended to be used with Jean Philippe Brucker's SVA > > patch [1] (Which is also in RFC stage). But it is not mandatory. This > > patchset is tested in the latest mainline kernel without the SVA patches. > > So it support only one process for each accelerator. > > > > With SVA support, WarpDrive can support multi-process in the same > > accelerator device. We tested it in our SoC integrated Accelerator (board > > ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. > > I have not fully inspected things nor do i know enough about > this Hisilicon ZIP accelerator to ascertain, but from glimpsing > at the code it seems that it is unsafe to use even with SVA due > to the doorbell. There is a comment talking about safetyness > in patch 7. > > Exposing thing to userspace is always enticing, but if it is > a security risk then it should clearly say so and maybe a > kernel boot flag should be necessary to allow such device to > be use. > > > My more general question is do we want to grow VFIO to become > a more generic device driver API. This patchset adds a command > queue concept to it (i don't think it exist today but i have > not follow VFIO closely). > > Why is that any better that existing driver model ? Where a > device create a device file (can be character device, block > device, ...). Such models also allow for direct hardware > access from userspace. For instance see the AMD KFD driver > inside drivers/gpu/drm/amd One motivation I guess, is that most accelerators lack of a well-abstracted high level APIs similar to GPU side (e.g. OpenCL clearly defines Shared Virtual Memory models). VFIO mdev might be an alternative common interface to enable SVA usages on various accelerators... > > So you can already do what you are doing with the Hisilicon > driver today without this new infrastructure. This only need > hardware that have command queue and doorbell like mechanisms. > > > Unlike mdev which unify a very high level concept, it seems > to me spimdev just introduce low level concept (namely command > queue) and i don't see the intrinsic value here. > > > Cheers, > Jérôme > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/ipmmu-vmsa: convert to SPDX identifiers
From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto --- drivers/iommu/ipmmu-vmsa.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index ee30be1..85447ec 100644 --- a/drivers/iommu/ipmmu-vmsa.c +++ b/drivers/iommu/ipmmu-vmsa.c @@ -1,11 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * IPMMU VMSA * * Copyright (C) 2014 Renesas Electronics Corporation - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. */ #include -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use the generic dma-noncoherent code for sh V3
On Tue, Jul 31, 2018 at 09:24:13AM +0200, Christoph Hellwig wrote: > On Tue, Jul 31, 2018 at 03:06:13PM +0900, Yoshinori Sato wrote: > > On Wed, 25 Jul 2018 18:40:38 +0900, > > Christoph Hellwig wrote: > > > > > > Hi all, > > > > > > can you review these patches to switch sh to use the generic > > > dma-noncoherent code? All the requirements are in mainline already > > > and we've switched various architectures over to it already. > > > > > > Changes since V2: > > > - drop a now obsolete export > > > > > > Changes since V1: > > > - fixed two stupid compile errors and verified them using a local > > >cross toolchain instead of the 0day buildbot > > > > Acked-by: Yoshinori Sato > > Do you want to pull this in through the sh tree? If not I'd be happy > to take it through the dma mapping tree. Usually I send the pull requests for sh tree, and I'm trying to figure out which patches are okay to merge and prepare one now, but if you're happy to take it through the dma mapping tree go ahead, and I'll focus on other sh stuff that needs attention. Rich ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
On Wed, Aug 01, 2018 at 06:22:14PM +0800, Kenneth Lee wrote: > From: Kenneth Lee > > WarpDrive is an accelerator framework to expose the hardware capabilities > directly to the user space. It makes use of the exist vfio and vfio-mdev > facilities. So the user application can send request and DMA to the > hardware without interaction with the kernel. This remove the latency > of syscall and context switch. > > The patchset contains documents for the detail. Please refer to it for more > information. > > This patchset is intended to be used with Jean Philippe Brucker's SVA > patch [1] (Which is also in RFC stage). But it is not mandatory. This > patchset is tested in the latest mainline kernel without the SVA patches. > So it support only one process for each accelerator. > > With SVA support, WarpDrive can support multi-process in the same > accelerator device. We tested it in our SoC integrated Accelerator (board > ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. I have not fully inspected things nor do i know enough about this Hisilicon ZIP accelerator to ascertain, but from glimpsing at the code it seems that it is unsafe to use even with SVA due to the doorbell. There is a comment talking about safetyness in patch 7. Exposing thing to userspace is always enticing, but if it is a security risk then it should clearly say so and maybe a kernel boot flag should be necessary to allow such device to be use. My more general question is do we want to grow VFIO to become a more generic device driver API. This patchset adds a command queue concept to it (i don't think it exist today but i have not follow VFIO closely). Why is that any better that existing driver model ? Where a device create a device file (can be character device, block device, ...). Such models also allow for direct hardware access from userspace. For instance see the AMD KFD driver inside drivers/gpu/drm/amd So you can already do what you are doing with the Hisilicon driver today without this new infrastructure. This only need hardware that have command queue and doorbell like mechanisms. Unlike mdev which unify a very high level concept, it seems to me spimdev just introduce low level concept (namely command queue) and i don't see the intrinsic value here. Cheers, Jérôme ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 3/7] vfio: add spimdev support
On 08/01/2018 03:22 AM, Kenneth Lee wrote: > From: Kenneth Lee > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from > the general vfio-mdev: > > 1. It shares its parent's IOMMU. > 2. There is no hardware resource attached to the mdev is created. The > hardware resource (A `queue') is allocated only when the mdev is > opened. > > Currently only the vfio type-1 driver is updated to make it to be aware > of. > > Signed-off-by: Kenneth Lee > Signed-off-by: Zaibo Xu > Signed-off-by: Zhou Wang > --- > drivers/vfio/Kconfig| 1 + > drivers/vfio/Makefile | 1 + > drivers/vfio/spimdev/Kconfig| 10 + > drivers/vfio/spimdev/Makefile | 3 + > drivers/vfio/spimdev/vfio_spimdev.c | 421 > drivers/vfio/vfio_iommu_type1.c | 136 - > include/linux/vfio_spimdev.h| 95 +++ > include/uapi/linux/vfio_spimdev.h | 28 ++ > 8 files changed, 689 insertions(+), 6 deletions(-) > create mode 100644 drivers/vfio/spimdev/Kconfig > create mode 100644 drivers/vfio/spimdev/Makefile > create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c > create mode 100644 include/linux/vfio_spimdev.h > create mode 100644 include/uapi/linux/vfio_spimdev.h > > diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig > new file mode 100644 > index ..1226301f9d0e > --- /dev/null > +++ b/drivers/vfio/spimdev/Kconfig > @@ -0,0 +1,10 @@ > +# SPDX-License-Identifier: GPL-2.0 > +config VFIO_SPIMDEV > + tristate "Support for Share Parent IOMMU MDEV" > + depends on VFIO_MDEV_DEVICE > + help > + Support for VFIO Share Parent IOMMU MDEV, which enable the kernel to enables > + support for the light weight hardware accelerator framework, > WrapDrive. support the lightweight hardware accelerator framework, WrapDrive. > + > + To compile this as a module, choose M here: the module will be called > + spimdev. -- ~Randy ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 8/9] ia64: remove machvec_dma_sync_{single,sg}
The original form of these was added (to the HP zx1 platform only) by
the following bitkeeper commit (by the way of the historic.git tree):
commit 66b99421d118a5ddd98a72913670b0fcf0a38d45
Author: Andrew Morton
Date: Sat Mar 13 17:05:37 2004 -0800
[PATCH] DMA: Fill gaping hole in DMA API interfaces.
From: "David S. Miller"
The commit does not explain why we'd need the memory barrier on ia64,
it never included the swiotlb or SGI IOMMU based platforms, and also
failed to address the map/unmap parts of the dma mapping interface,
which should provide the same ordering semantics and actually are
commonly used. The conclusion of this is that they were added in
error and should be removed.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 4
arch/ia64/include/asm/dma-mapping.h | 5 -
arch/ia64/kernel/machvec.c | 16
arch/ia64/kernel/pci-dma.c | 5 -
4 files changed, 30 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index ee5b652d320a..e8da6503ed2f 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -2207,10 +2207,6 @@ const struct dma_map_ops sba_dma_ops = {
.unmap_page = sba_unmap_page,
.map_sg = sba_map_sg_attrs,
.unmap_sg = sba_unmap_sg_attrs,
- .sync_single_for_cpu= machvec_dma_sync_single,
- .sync_sg_for_cpu= machvec_dma_sync_sg,
- .sync_single_for_device = machvec_dma_sync_single,
- .sync_sg_for_device = machvec_dma_sync_sg,
.dma_supported = sba_dma_supported,
.mapping_error = sba_dma_mapping_error,
};
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
index 76e4d6632d68..2b8cd4a6d958 100644
--- a/arch/ia64/include/asm/dma-mapping.h
+++ b/arch/ia64/include/asm/dma-mapping.h
@@ -16,11 +16,6 @@ extern const struct dma_map_ops *dma_ops;
extern struct ia64_machine_vector ia64_mv;
extern void set_iommu_machvec(void);
-extern void machvec_dma_sync_single(struct device *, dma_addr_t, size_t,
- enum dma_data_direction);
-extern void machvec_dma_sync_sg(struct device *, struct scatterlist *, int,
- enum dma_data_direction);
-
static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
{
return platform_dma_get_ops(NULL);
diff --git a/arch/ia64/kernel/machvec.c b/arch/ia64/kernel/machvec.c
index 7bfe98859911..1b604d02250b 100644
--- a/arch/ia64/kernel/machvec.c
+++ b/arch/ia64/kernel/machvec.c
@@ -73,19 +73,3 @@ machvec_timer_interrupt (int irq, void *dev_id)
{
}
EXPORT_SYMBOL(machvec_timer_interrupt);
-
-void
-machvec_dma_sync_single(struct device *hwdev, dma_addr_t dma_handle, size_t
size,
- enum dma_data_direction dir)
-{
- mb();
-}
-EXPORT_SYMBOL(machvec_dma_sync_single);
-
-void
-machvec_dma_sync_sg(struct device *hwdev, struct scatterlist *sg, int n,
- enum dma_data_direction dir)
-{
- mb();
-}
-EXPORT_SYMBOL(machvec_dma_sync_sg);
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index afb43677f9ca..5a5bf5a82ac2 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -41,11 +41,6 @@ void __init pci_iommu_alloc(void)
{
dma_ops = _dma_ops;
- intel_dma_ops.sync_single_for_cpu = machvec_dma_sync_single;
- intel_dma_ops.sync_sg_for_cpu = machvec_dma_sync_sg;
- intel_dma_ops.sync_single_for_device = machvec_dma_sync_single;
- intel_dma_ops.sync_sg_for_device = machvec_dma_sync_sg;
-
/*
* The order of these functions is important for
* fall-back/fail-over reasons
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 9/9] intel-iommu: mark intel_dma_ops static
ia64 currently explicitly assigns it to dma_ops, but that same work is
already done by intel_iommu_init a little later, so we can remove the
duplicate assignment and mark the variable static.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 4
drivers/iommu/intel-iommu.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 5a5bf5a82ac2..fe988c49f01c 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -24,8 +24,6 @@ int force_iommu __read_mostly;
int iommu_pass_through;
-extern struct dma_map_ops intel_dma_ops;
-
static int __init pci_iommu_init(void)
{
if (iommu_detected)
@@ -39,8 +37,6 @@ fs_initcall(pci_iommu_init);
void __init pci_iommu_alloc(void)
{
- dma_ops = _dma_ops;
-
/*
* The order of these functions is important for
* fall-back/fail-over reasons
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 1be2609bd094..2da100e042fb 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3889,7 +3889,7 @@ static int intel_mapping_error(struct device *dev,
dma_addr_t dma_addr)
return !dma_addr;
}
-const struct dma_map_ops intel_dma_ops = {
+static const struct dma_map_ops intel_dma_ops = {
.alloc = intel_alloc_coherent,
.free = intel_free_coherent,
.map_sg = intel_map_sg,
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 6/9] ia64: remove the unused iommu_dma_init function
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/iommu.h | 1 -
arch/ia64/kernel/pci-dma.c| 6 --
2 files changed, 7 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
index 5397e5aa3704..7429a72f3f92 100644
--- a/arch/ia64/include/asm/iommu.h
+++ b/arch/ia64/include/asm/iommu.h
@@ -15,7 +15,6 @@ extern int iommu_detected;
#define no_iommu (1)
#define iommu_detected (0)
#endif
-extern void iommu_dma_init(void);
extern void machvec_init(const char *name);
#endif
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 936af0ec7f8f..afb43677f9ca 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -37,12 +37,6 @@ static int __init pci_iommu_init(void)
/* Must execute after PCI subsystem */
fs_initcall(pci_iommu_init);
-void __init
-iommu_dma_init(void)
-{
- return;
-}
-
void __init pci_iommu_alloc(void)
{
dma_ops = _dma_ops;
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 7/9] ia64/sn2: remove no-ops dma sync methods
These do nothing but duplicating an assert that would have triggered
earlier on setting the dma mask, so remove them.
Signed-off-by: Christoph Hellwig
---
arch/ia64/sn/pci/pci_dma.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
index 74c934a997bb..3b944fba0a3e 100644
--- a/arch/ia64/sn/pci/pci_dma.c
+++ b/arch/ia64/sn/pci/pci_dma.c
@@ -314,31 +314,6 @@ static int sn_dma_map_sg(struct device *dev, struct
scatterlist *sgl,
return nhwentries;
}
-static void sn_dma_sync_single_for_cpu(struct device *dev, dma_addr_t
dma_handle,
- size_t size, enum dma_data_direction dir)
-{
- BUG_ON(!dev_is_pci(dev));
-}
-
-static void sn_dma_sync_single_for_device(struct device *dev, dma_addr_t
dma_handle,
- size_t size,
- enum dma_data_direction dir)
-{
- BUG_ON(!dev_is_pci(dev));
-}
-
-static void sn_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
- int nelems, enum dma_data_direction dir)
-{
- BUG_ON(!dev_is_pci(dev));
-}
-
-static void sn_dma_sync_sg_for_device(struct device *dev, struct scatterlist
*sg,
- int nelems, enum dma_data_direction dir)
-{
- BUG_ON(!dev_is_pci(dev));
-}
-
static int sn_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
return 0;
@@ -467,10 +442,6 @@ static struct dma_map_ops sn_dma_ops = {
.unmap_page = sn_dma_unmap_page,
.map_sg = sn_dma_map_sg,
.unmap_sg = sn_dma_unmap_sg,
- .sync_single_for_cpu= sn_dma_sync_single_for_cpu,
- .sync_sg_for_cpu= sn_dma_sync_sg_for_cpu,
- .sync_single_for_device = sn_dma_sync_single_for_device,
- .sync_sg_for_device = sn_dma_sync_sg_for_device,
.mapping_error = sn_dma_mapping_error,
.dma_supported = sn_dma_supported,
};
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5/9] ia64: remove the unused pci_iommu_shutdown function
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/iommu.h | 1 -
arch/ia64/kernel/pci-dma.c| 5 -
2 files changed, 6 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
index 156b9d8e1932..5397e5aa3704 100644
--- a/arch/ia64/include/asm/iommu.h
+++ b/arch/ia64/include/asm/iommu.h
@@ -5,7 +5,6 @@
/* 10 seconds */
#define DMAR_OPERATION_TIMEOUT (((cycles_t) local_cpu_data->itc_freq)*10)
-extern void pci_iommu_shutdown(void);
extern void no_iommu_init(void);
#ifdef CONFIG_INTEL_IOMMU
extern int force_iommu, no_iommu;
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 924966e5aa25..936af0ec7f8f 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -37,11 +37,6 @@ static int __init pci_iommu_init(void)
/* Must execute after PCI subsystem */
fs_initcall(pci_iommu_init);
-void pci_iommu_shutdown(void)
-{
- return;
-}
-
void __init
iommu_dma_init(void)
{
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 4/9] ia64: remove the unused bad_dma_address symbol
Signed-off-by: Christoph Hellwig --- arch/ia64/kernel/pci-dma.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c index 3c2884bef3d4..924966e5aa25 100644 --- a/arch/ia64/kernel/pci-dma.c +++ b/arch/ia64/kernel/pci-dma.c @@ -15,9 +15,6 @@ #include #include -dma_addr_t bad_dma_address __read_mostly; -EXPORT_SYMBOL(bad_dma_address); - int no_iommu __read_mostly; #ifdef CONFIG_IOMMU_DEBUG int force_iommu __read_mostly = 1; -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 3/9] ia64: remove iommu_dma_supported
The generic dma_direct_supported helper already used by intel-iommu on
x86 does a better job than the ia64 reimplementation.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 13 -
drivers/iommu/intel-iommu.c | 2 --
2 files changed, 15 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 50b6ad282a90..3c2884bef3d4 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -51,18 +51,6 @@ iommu_dma_init(void)
return;
}
-int iommu_dma_supported(struct device *dev, u64 mask)
-{
- /* Copied from i386. Doesn't make much sense, because it will
- only work for pci_alloc_coherent.
- The caller just has to use GFP_DMA in this case. */
- if (mask < DMA_BIT_MASK(24))
- return 0;
-
- return 1;
-}
-EXPORT_SYMBOL(iommu_dma_supported);
-
void __init pci_iommu_alloc(void)
{
dma_ops = _dma_ops;
@@ -71,7 +59,6 @@ void __init pci_iommu_alloc(void)
intel_dma_ops.sync_sg_for_cpu = machvec_dma_sync_sg;
intel_dma_ops.sync_single_for_device = machvec_dma_sync_single;
intel_dma_ops.sync_sg_for_device = machvec_dma_sync_sg;
- intel_dma_ops.dma_supported = iommu_dma_supported;
/*
* The order of these functions is important for
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 115ff26e9ced..1be2609bd094 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3897,9 +3897,7 @@ const struct dma_map_ops intel_dma_ops = {
.map_page = intel_map_page,
.unmap_page = intel_unmap_page,
.mapping_error = intel_mapping_error,
-#ifdef CONFIG_X86
.dma_supported = dma_direct_supported,
-#endif
};
static inline int iommu_domain_cache_init(void)
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/9] ia64: remove the dead iommu_sac_force variable
Looks like copy and paste from x86 that never actually got used.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index b5df084c0af4..50b6ad282a90 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -18,8 +18,6 @@
dma_addr_t bad_dma_address __read_mostly;
EXPORT_SYMBOL(bad_dma_address);
-static int iommu_sac_force __read_mostly;
-
int no_iommu __read_mostly;
#ifdef CONFIG_IOMMU_DEBUG
int force_iommu __read_mostly = 1;
@@ -61,23 +59,6 @@ int iommu_dma_supported(struct device *dev, u64 mask)
if (mask < DMA_BIT_MASK(24))
return 0;
- /* Tell the device to use SAC when IOMMU force is on. This
- allows the driver to use cheaper accesses in some cases.
-
- Problem with this is that if we overflow the IOMMU area and
- return DAC as fallback address the device may not handle it
- correctly.
-
- As a special case some controllers have a 39bit address
- mode that is as efficient as 32bit (aic79xx). Don't force
- SAC for these. Assume all masks <= 40 bits are of this
- type. Normally this doesn't make any difference, but gives
- more gentle handling of IOMMU overflow. */
- if (iommu_sac_force && (mask >= DMA_BIT_MASK(40))) {
- dev_info(dev, "Force SAC with mask %llx\n", mask);
- return 0;
- }
-
return 1;
}
EXPORT_SYMBOL(iommu_dma_supported);
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/9] ia64: remove the kern_mem_attribute export
No actually used anywhere. Signed-off-by: Christoph Hellwig --- arch/ia64/kernel/efi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c index 9c09bf390cce..f77d80edddfe 100644 --- a/arch/ia64/kernel/efi.c +++ b/arch/ia64/kernel/efi.c @@ -842,7 +842,6 @@ kern_mem_attribute (unsigned long phys_addr, unsigned long size) } while (md); return 0; /* never reached */ } -EXPORT_SYMBOL(kern_mem_attribute); int valid_phys_addr_range (phys_addr_t phys_addr, unsigned long size) -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
DMA related cleanups for IA64
Hi all, this is a resend of the last two series plus additional cleanups. The driver of it were the odd dma barriers in the ia64 sync_single_* methods, but once I started to look into that area the fallback got bigger and bigger.. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC PATCH 7/7] vfio/spimdev: add user sample for spimdev
From: Kenneth Lee This is the sample code to demostrate how WrapDrive user application should be. It contains: 1. wd.[ch], the common library to provide WrapDrive interface. 2. drv/*, the user driver to access the hardware upon spimdev 3. test/*, the test application to use WrapDrive interface to access the hardware queue(s) of the accelerator. The Hisilicon HIP08 ZIP accelerator is used in this sample. Signed-off-by: Zaibo Xu Signed-off-by: Kenneth Lee Signed-off-by: Hao Fang Signed-off-by: Zhou Wang --- samples/warpdrive/AUTHORS | 2 + samples/warpdrive/ChangeLog| 1 + samples/warpdrive/Makefile.am | 9 + samples/warpdrive/NEWS | 1 + samples/warpdrive/README | 32 +++ samples/warpdrive/autogen.sh | 3 + samples/warpdrive/cleanup.sh | 13 + samples/warpdrive/configure.ac | 52 samples/warpdrive/drv/hisi_qm_udrv.c | 223 + samples/warpdrive/drv/hisi_qm_udrv.h | 53 samples/warpdrive/test/Makefile.am | 7 + samples/warpdrive/test/comp_hw.h | 23 ++ samples/warpdrive/test/test_hisi_zip.c | 204 samples/warpdrive/wd.c | 325 + samples/warpdrive/wd.h | 153 samples/warpdrive/wd_adapter.c | 74 ++ samples/warpdrive/wd_adapter.h | 43 17 files changed, 1218 insertions(+) create mode 100644 samples/warpdrive/AUTHORS create mode 100644 samples/warpdrive/ChangeLog create mode 100644 samples/warpdrive/Makefile.am create mode 100644 samples/warpdrive/NEWS create mode 100644 samples/warpdrive/README create mode 100755 samples/warpdrive/autogen.sh create mode 100755 samples/warpdrive/cleanup.sh create mode 100644 samples/warpdrive/configure.ac create mode 100644 samples/warpdrive/drv/hisi_qm_udrv.c create mode 100644 samples/warpdrive/drv/hisi_qm_udrv.h create mode 100644 samples/warpdrive/test/Makefile.am create mode 100644 samples/warpdrive/test/comp_hw.h create mode 100644 samples/warpdrive/test/test_hisi_zip.c create mode 100644 samples/warpdrive/wd.c create mode 100644 samples/warpdrive/wd.h create mode 100644 samples/warpdrive/wd_adapter.c create mode 100644 samples/warpdrive/wd_adapter.h diff --git a/samples/warpdrive/AUTHORS b/samples/warpdrive/AUTHORS new file mode 100644 index ..fe7dc2413b0d --- /dev/null +++ b/samples/warpdrive/AUTHORS @@ -0,0 +1,2 @@ +Kenneth Lee +Zaibo Xu diff --git a/samples/warpdrive/ChangeLog b/samples/warpdrive/ChangeLog new file mode 100644 index ..b1b716105590 --- /dev/null +++ b/samples/warpdrive/ChangeLog @@ -0,0 +1 @@ +init diff --git a/samples/warpdrive/Makefile.am b/samples/warpdrive/Makefile.am new file mode 100644 index ..41154a880a97 --- /dev/null +++ b/samples/warpdrive/Makefile.am @@ -0,0 +1,9 @@ +ACLOCAL_AMFLAGS = -I m4 +AUTOMAKE_OPTIONS = foreign subdir-objects +AM_CFLAGS=-Wall -O0 -fno-strict-aliasing + +lib_LTLIBRARIES=libwd.la +libwd_la_SOURCES=wd.c wd_adapter.c wd.h wd_adapter.h \ +drv/hisi_qm_udrv.c drv/hisi_qm_udrv.h + +SUBDIRS=. test diff --git a/samples/warpdrive/NEWS b/samples/warpdrive/NEWS new file mode 100644 index ..b1b716105590 --- /dev/null +++ b/samples/warpdrive/NEWS @@ -0,0 +1 @@ +init diff --git a/samples/warpdrive/README b/samples/warpdrive/README new file mode 100644 index ..3adf66b112fc --- /dev/null +++ b/samples/warpdrive/README @@ -0,0 +1,32 @@ +WD User Land Demonstration +== + +This directory contains some applications and libraries to demonstrate how a + +WrapDrive application can be constructed. + + +As a demo, we try to make it simple and clear for understanding. It is not + +supposed to be used in business scenario. + + +The directory contains the following elements: + +wd.[ch] + A demonstration WrapDrive fundamental library which wraps the basic + operations to the WrapDrive-ed device. + +wd_adapter.[ch] + User driver adaptor for wd.[ch] + +wd_utils.[ch] + Some utitlities function used by WD and its drivers + +drv/* + User drivers. It helps to fulfill the semantic of wd.[ch] for + particular hardware + +test/* + Test applications to use the wrapdrive library + diff --git a/samples/warpdrive/autogen.sh b/samples/warpdrive/autogen.sh new file mode 100755 index ..58deaf49de2a --- /dev/null +++ b/samples/warpdrive/autogen.sh @@ -0,0 +1,3 @@ +#!/bin/sh -x + +autoreconf -i -f -v diff --git a/samples/warpdrive/cleanup.sh b/samples/warpdrive/cleanup.sh new file mode 100755 index ..c5f3d21e5dc1 --- /dev/null +++ b/samples/warpdrive/cleanup.sh @@ -0,0 +1,13 @@ +#!/bin/sh + +if [ -r Makefile ]; then + make distclean +fi + +FILES="aclocal.m4 autom4te.cache compile config.guess config.h.in config.log \ + config.status config.sub configure cscope.out depcomp install-sh \ +
[RFC PATCH 6/7] crypto: add spimdev support to Hisilicon QM
From: Kenneth Lee
The commit add spimdev support to the Hislicon QM driver, any
accelerator that use QM can share its queues to the user space.
Signed-off-by: Kenneth Lee
Signed-off-by: Zhou Wang
Signed-off-by: Hao Fang
Signed-off-by: Zaibo Xu
---
drivers/crypto/hisilicon/qm.c | 150 ++
drivers/crypto/hisilicon/qm.h | 12 +++
2 files changed, 162 insertions(+)
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index e779bc661500..06da8387dc58 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -667,6 +667,146 @@ int hisi_qp_send(struct hisi_qp *qp, void *msg)
}
EXPORT_SYMBOL_GPL(hisi_qp_send);
+#ifdef CONFIG_CRYPTO_DEV_HISI_SPIMDEV
+/* mdev->supported_type_groups */
+static struct attribute *hisi_qm_type_attrs[] = {
+ VFIO_SPIMDEV_DEFAULT_MDEV_TYPE_ATTRS,
+ NULL,
+};
+static struct attribute_group hisi_qm_type_group = {
+ .attrs = hisi_qm_type_attrs,
+};
+static struct attribute_group *mdev_type_groups[] = {
+ _qm_type_group,
+ NULL,
+};
+
+static void qm_qp_event_notifier(struct hisi_qp *qp)
+{
+ vfio_spimdev_wake_up(qp->spimdev_q);
+}
+
+static int hisi_qm_get_queue(struct vfio_spimdev *spimdev, unsigned long arg,
+ struct vfio_spimdev_queue **q)
+{
+ struct qm_info *qm = spimdev->priv;
+ struct hisi_qp *qp = NULL;
+ struct vfio_spimdev_queue *wd_q;
+ u8 alg_type = 0; /* fix me here */
+ int ret;
+ int pasid = arg;
+
+ qp = hisi_qm_create_qp(qm, alg_type);
+ if (IS_ERR(qp))
+ return PTR_ERR(qp);
+
+ wd_q = kzalloc(sizeof(struct vfio_spimdev_queue), GFP_KERNEL);
+ if (!wd_q) {
+ ret = -ENOMEM;
+ goto err_with_qp;
+ }
+
+ wd_q->priv = qp;
+ wd_q->spimdev = spimdev;
+ wd_q->qid = (u16)ret;
+ *q = wd_q;
+ qp->spimdev_q = wd_q;
+ qp->event_cb = qm_qp_event_notifier;
+
+ ret = hisi_qm_start_qp(qp, arg);
+ if (ret < 0)
+ goto err_with_wd_q;
+
+ return ret;
+
+err_with_wd_q:
+ kfree(wd_q);
+err_with_qp:
+ hisi_qm_release_qp(qp);
+ return ret;
+}
+
+static int hisi_qm_put_queue(struct vfio_spimdev_queue *q)
+{
+ struct hisi_qp *qp = q->priv;
+
+ /* need to stop hardware, but can not support in v1 */
+ hisi_qm_release_qp(qp);
+ kfree(q);
+ return 0;
+}
+
+/* map sq/cq/doorbell to user space */
+static int hisi_qm_mmap(struct vfio_spimdev_queue *q,
+ struct vm_area_struct *vma)
+{
+ struct hisi_qp *qp = (struct hisi_qp *)q->priv;
+ struct qm_info *qm = qp->qm;
+ struct device *dev = >pdev->dev;
+ size_t sz = vma->vm_end - vma->vm_start;
+ u8 region;
+
+ vma->vm_flags |= (VM_IO | VM_LOCKED | VM_DONTEXPAND | VM_DONTDUMP);
+ region = _VFIO_SPIMDEV_REGION(vma->vm_pgoff);
+
+ switch (region) {
+ case 0:
+ if (sz > PAGE_SIZE)
+ return -EINVAL;
+ /*
+* Warning: This is not safe as multiple queues use the same
+* doorbell, v1 hardware interface problem. v2 will fix it
+*/
+ return remap_pfn_range(vma, vma->vm_start,
+ qm->phys_base >> PAGE_SHIFT,
+ sz, pgprot_noncached(vma->vm_page_prot));
+ case 1:
+ vma->vm_pgoff = 0;
+ if (sz > qp->scqe.size)
+ return -EINVAL;
+
+ return dma_mmap_coherent(dev, vma, qp->scqe.addr, qp->scqe.dma,
+ sz);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct vfio_spimdev_ops qm_ops = {
+ .get_queue = hisi_qm_get_queue,
+ .put_queue = hisi_qm_put_queue,
+ .mmap = hisi_qm_mmap,
+};
+
+static int qm_register_spimdev(struct qm_info *qm)
+{
+ struct pci_dev *pdev = qm->pdev;
+ struct vfio_spimdev *spimdev = >spimdev;
+
+ spimdev->iommu_type = VFIO_TYPE1_IOMMU;
+#ifdef CONFIG_IOMMU_SVA
+ spimdev->dma_flag = VFIO_SPIMDEV_DMA_MULTI_PROC_MAP;
+#else
+ spimdev->dma_flag = VFIO_SPIMDEV_DMA_SINGLE_PROC_MAP;
+#endif
+ spimdev->owner = THIS_MODULE;
+ spimdev->name = qm->dev_name;
+ spimdev->dev = >dev;
+ spimdev->is_vf = pdev->is_virtfn;
+ spimdev->priv = qm;
+ spimdev->api_ver = "hisi_qm_v1";
+ spimdev->flags = 0;
+
+ spimdev->mdev_fops.mdev_attr_groups = qm->mdev_dev_groups;
+ hisi_qm_type_group.name = qm->dev_name;
+ spimdev->mdev_fops.supported_type_groups = mdev_type_groups;
+ spimdev->ops = _ops;
+
+ return vfio_spimdev_register(spimdev);
+}
+#endif
+
int hisi_qm_init(const char *dev_name, struct qm_info *qm)
{
int ret;
@@ -804,6 +944,12 @@ int hisi_qm_start(struct qm_info *qm)
if (ret)
[RFC PATCH 5/7] crypto: Add Hisilicon Zip driver
From: Kenneth Lee
The Hisilicon ZIP accelerator implements zlib and gzip algorithm support
for the software. It uses Hisilicon QM as the interface to the CPU, so it
is shown up as a PCIE device to the CPU with a group of queues.
This commit provides PCIE driver to the accelerator and register it to
the crypto subsystem.
Signed-off-by: Kenneth Lee
Signed-off-by: Zhou Wang
Signed-off-by: Hao Fang
---
drivers/crypto/hisilicon/Kconfig | 7 +
drivers/crypto/hisilicon/Makefile | 1 +
drivers/crypto/hisilicon/zip/Makefile | 2 +
drivers/crypto/hisilicon/zip/zip.h| 55
drivers/crypto/hisilicon/zip/zip_crypto.c | 358 ++
drivers/crypto/hisilicon/zip/zip_crypto.h | 18 ++
drivers/crypto/hisilicon/zip/zip_main.c | 182 +++
7 files changed, 623 insertions(+)
create mode 100644 drivers/crypto/hisilicon/zip/Makefile
create mode 100644 drivers/crypto/hisilicon/zip/zip.h
create mode 100644 drivers/crypto/hisilicon/zip/zip_crypto.c
create mode 100644 drivers/crypto/hisilicon/zip/zip_crypto.h
create mode 100644 drivers/crypto/hisilicon/zip/zip_main.c
diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 0dd30f84b90e..48ad682e0a52 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -6,3 +6,10 @@ config CRYPTO_DEV_HISILICON
config CRYPTO_DEV_HISI_QM
tristate
depends on ARM64 && PCI
+
+config CRYPTO_DEV_HISI_ZIP
+ tristate "Support for HISI ZIP Driver"
+ depends on ARM64 && CRYPTO_DEV_HISILICON
+ select CRYPTO_DEV_HISI_QM
+ help
+ Support for HiSilicon HIP08 ZIP Driver
diff --git a/drivers/crypto/hisilicon/Makefile
b/drivers/crypto/hisilicon/Makefile
index 3378afc11703..62e40b093c49 100644
--- a/drivers/crypto/hisilicon/Makefile
+++ b/drivers/crypto/hisilicon/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_HISI_QM) += qm.o
+obj-$(CONFIG_CRYPTO_DEV_HISI_ZIP) += zip/
diff --git a/drivers/crypto/hisilicon/zip/Makefile
b/drivers/crypto/hisilicon/zip/Makefile
new file mode 100644
index ..a936f099ee22
--- /dev/null
+++ b/drivers/crypto/hisilicon/zip/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_HISI_ZIP) += hisi_zip.o
+hisi_zip-objs = zip_main.o zip_crypto.o
diff --git a/drivers/crypto/hisilicon/zip/zip.h
b/drivers/crypto/hisilicon/zip/zip.h
new file mode 100644
index ..a0c56e4aeb51
--- /dev/null
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef HISI_ZIP_H
+#define HISI_ZIP_H
+
+#include
+#include "../qm.h"
+
+#define HZIP_SQE_SIZE 128
+#define HZIP_SQ_SIZE (HZIP_SQE_SIZE * QM_Q_DEPTH)
+#define QM_CQ_SIZE (QM_CQE_SIZE * QM_Q_DEPTH)
+#define HZIP_PF_DEF_Q_NUM 64
+#define HZIP_PF_DEF_Q_BASE 0
+
+struct hisi_zip {
+ struct qm_info qm;
+ struct list_head list;
+
+#ifdef CONFIG_CRYPTO_DEV_HISI_SPIMDEV
+ struct vfio_spimdev *spimdev;
+#endif
+};
+
+struct hisi_zip_sqe {
+ __u32 consumed;
+ __u32 produced;
+ __u32 comp_data_length;
+ __u32 dw3;
+ __u32 input_data_length;
+ __u32 lba_l;
+ __u32 lba_h;
+ __u32 dw7;
+ __u32 dw8;
+ __u32 dw9;
+ __u32 dw10;
+ __u32 priv_info;
+ __u32 dw12;
+ __u32 tag;
+ __u32 dest_avail_out;
+ __u32 rsvd0;
+ __u32 comp_head_addr_l;
+ __u32 comp_head_addr_h;
+ __u32 source_addr_l;
+ __u32 source_addr_h;
+ __u32 dest_addr_l;
+ __u32 dest_addr_h;
+ __u32 stream_ctx_addr_l;
+ __u32 stream_ctx_addr_h;
+ __u32 cipher_key1_addr_l;
+ __u32 cipher_key1_addr_h;
+ __u32 cipher_key2_addr_l;
+ __u32 cipher_key2_addr_h;
+ __u32 rsvd1[4];
+};
+
+#endif
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
new file mode 100644
index ..a3a5a6a6554d
--- /dev/null
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -0,0 +1,358 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018 (c) HiSilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include "../qm.h"
+#include "zip.h"
+
+#define INPUT_BUFFER_SIZE (64 * 1024)
+#define OUTPUT_BUFFER_SIZE (64 * 1024)
+
+extern struct list_head hisi_zip_list;
+
+#define COMP_NAME_TO_TYPE(alg_name)\
+ (!strcmp((alg_name), "zlib-deflate") ? 0x02 : \
+!strcmp((alg_name), "gzip") ? 0x03 : 0)\
+
+struct hisi_zip_buffer {
+ u8 *input;
+ dma_addr_t input_dma;
+ u8 *output;
+ dma_addr_t output_dma;
+};
+
+struct hisi_zip_qp_ctx {
[RFC PATCH 4/7] crypto: add hisilicon Queue Manager driver
From: Kenneth Lee Hisilicon QM is a general IP used by some Hisilicon accelerators. It provides a general PCIE interface for the CPU and the accelerator to share a group of queues. This commit includes a library used by the accelerator driver to access the QM hardware. Signed-off-by: Kenneth Lee Signed-off-by: Zhou Wang Signed-off-by: Hao Fang --- drivers/crypto/Kconfig| 2 + drivers/crypto/Makefile | 1 + drivers/crypto/hisilicon/Kconfig | 8 + drivers/crypto/hisilicon/Makefile | 1 + drivers/crypto/hisilicon/qm.c | 855 ++ drivers/crypto/hisilicon/qm.h | 111 6 files changed, 978 insertions(+) create mode 100644 drivers/crypto/hisilicon/Kconfig create mode 100644 drivers/crypto/hisilicon/Makefile create mode 100644 drivers/crypto/hisilicon/qm.c create mode 100644 drivers/crypto/hisilicon/qm.h diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 43cccf6aff61..8da1e3170eb4 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -746,4 +746,6 @@ config CRYPTO_DEV_CCREE cryptographic operations on the system REE. If unsure say Y. +source "drivers/crypto/hisilicon/Kconfig" + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 7ae87b4f6c8d..32e9bf64a42f 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -45,3 +45,4 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/ obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/ obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/ obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/ +obj-$(CONFIG_CRYPTO_DEV_HISILICON) += hisilicon/ diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig new file mode 100644 index ..0dd30f84b90e --- /dev/null +++ b/drivers/crypto/hisilicon/Kconfig @@ -0,0 +1,8 @@ +config CRYPTO_DEV_HISILICON + tristate "Support for HISILICON CRYPTO ACCELERATOR" + help + Enable this to use Hisilicon Hardware Accelerators + +config CRYPTO_DEV_HISI_QM + tristate + depends on ARM64 && PCI diff --git a/drivers/crypto/hisilicon/Makefile b/drivers/crypto/hisilicon/Makefile new file mode 100644 index ..3378afc11703 --- /dev/null +++ b/drivers/crypto/hisilicon/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CRYPTO_DEV_HISI_QM) += qm.o diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c new file mode 100644 index ..e779bc661500 --- /dev/null +++ b/drivers/crypto/hisilicon/qm.c @@ -0,0 +1,855 @@ +// SPDX-License-Identifier: GPL-2.0+ +#include +#include +#include +#include +#include +#include +#include "qm.h" + +#define QM_DEF_Q_NUM 128 + +/* eq/aeq irq enable */ +#define QM_VF_AEQ_INT_SOURCE 0x0 +#define QM_VF_AEQ_INT_MASK 0x4 +#define QM_VF_EQ_INT_SOURCE0x8 +#define QM_VF_EQ_INT_MASK 0xc + +/* mailbox */ +#define MAILBOX_CMD_SQC0x0 +#define MAILBOX_CMD_CQC0x1 +#define MAILBOX_CMD_EQC0x2 +#define MAILBOX_CMD_AEQC 0x3 +#define MAILBOX_CMD_SQC_BT 0x4 +#define MAILBOX_CMD_CQC_BT 0x5 + +#define MAILBOX_CMD_SEND_BASE 0x300 +#define MAILBOX_EVENT_SHIFT8 +#define MAILBOX_STATUS_SHIFT 9 +#define MAILBOX_BUSY_SHIFT 13 +#define MAILBOX_OP_SHIFT 14 +#define MAILBOX_QUEUE_SHIFT16 + +/* sqc shift */ +#define SQ_HEAD_SHIFT 0 +#define SQ_TAIL_SHIFI 16 +#define SQ_HOP_NUM_SHIFT 0 +#define SQ_PAGE_SIZE_SHIFT 4 +#define SQ_BUF_SIZE_SHIFT 8 +#define SQ_SQE_SIZE_SHIFT 12 +#define SQ_HEAD_IDX_SIG_SHIFT 0 +#define SQ_TAIL_IDX_SIG_SHIFT 0 +#define SQ_CQN_SHIFT 0 +#define SQ_PRIORITY_SHIFT 0 +#define SQ_ORDERS_SHIFT4 +#define SQ_TYPE_SHIFT 8 + +#define SQ_TYPE_MASK 0xf + +/* cqc shift */ +#define CQ_HEAD_SHIFT 0 +#define CQ_TAIL_SHIFI 16 +#define CQ_HOP_NUM_SHIFT 0 +#define CQ_PAGE_SIZE_SHIFT 4 +#define CQ_BUF_SIZE_SHIFT 8 +#define CQ_SQE_SIZE_SHIFT 12 +#define CQ_PASID 0 +#define CQ_HEAD_IDX_SIG_SHIFT 0 +#define CQ_TAIL_IDX_SIG_SHIFT 0 +#define CQ_CQN_SHIFT 0 +#define CQ_PRIORITY_SHIFT 16 +#define CQ_ORDERS_SHIFT0 +#define CQ_TYPE_SHIFT 0 +#define CQ_PHASE_SHIFT 0 +#define CQ_FLAG_SHIFT 1 + +#define CQC_HEAD_INDEX(cqc)((cqc)->cq_head) +#define CQC_PHASE(cqc) (((cqc)->dw6) & 0x1) +#define CQC_CQ_ADDRESS(cqc)(((u64)((cqc)->cq_base_h) << 32) | \ +((cqc)->cq_base_l)) +#define CQC_PHASE_BIT
[RFC PATCH 3/7] vfio: add spimdev support
From: Kenneth Lee
SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from
the general vfio-mdev:
1. It shares its parent's IOMMU.
2. There is no hardware resource attached to the mdev is created. The
hardware resource (A `queue') is allocated only when the mdev is
opened.
Currently only the vfio type-1 driver is updated to make it to be aware
of.
Signed-off-by: Kenneth Lee
Signed-off-by: Zaibo Xu
Signed-off-by: Zhou Wang
---
drivers/vfio/Kconfig| 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/spimdev/Kconfig| 10 +
drivers/vfio/spimdev/Makefile | 3 +
drivers/vfio/spimdev/vfio_spimdev.c | 421
drivers/vfio/vfio_iommu_type1.c | 136 -
include/linux/vfio_spimdev.h| 95 +++
include/uapi/linux/vfio_spimdev.h | 28 ++
8 files changed, 689 insertions(+), 6 deletions(-)
create mode 100644 drivers/vfio/spimdev/Kconfig
create mode 100644 drivers/vfio/spimdev/Makefile
create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c
create mode 100644 include/linux/vfio_spimdev.h
create mode 100644 include/uapi/linux/vfio_spimdev.h
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index c84333eb5eb5..3719eba72ef1 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -47,4 +47,5 @@ menuconfig VFIO_NOIOMMU
source "drivers/vfio/pci/Kconfig"
source "drivers/vfio/platform/Kconfig"
source "drivers/vfio/mdev/Kconfig"
+source "drivers/vfio/spimdev/Kconfig"
source "virt/lib/Kconfig"
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index de67c4725cce..28f3ef0cdce1 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
obj-$(CONFIG_VFIO_PCI) += pci/
obj-$(CONFIG_VFIO_PLATFORM) += platform/
obj-$(CONFIG_VFIO_MDEV) += mdev/
+obj-$(CONFIG_VFIO_SPIMDEV) += spimdev/
diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig
new file mode 100644
index ..1226301f9d0e
--- /dev/null
+++ b/drivers/vfio/spimdev/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+config VFIO_SPIMDEV
+ tristate "Support for Share Parent IOMMU MDEV"
+ depends on VFIO_MDEV_DEVICE
+ help
+ Support for VFIO Share Parent IOMMU MDEV, which enable the kernel to
+ support for the light weight hardware accelerator framework,
WrapDrive.
+
+ To compile this as a module, choose M here: the module will be called
+ spimdev.
diff --git a/drivers/vfio/spimdev/Makefile b/drivers/vfio/spimdev/Makefile
new file mode 100644
index ..d02fb69c37e4
--- /dev/null
+++ b/drivers/vfio/spimdev/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+spimdev-y := spimdev.o
+obj-$(CONFIG_VFIO_SPIMDEV) += vfio_spimdev.o
diff --git a/drivers/vfio/spimdev/vfio_spimdev.c
b/drivers/vfio/spimdev/vfio_spimdev.c
new file mode 100644
index ..1b6910c9d27d
--- /dev/null
+++ b/drivers/vfio/spimdev/vfio_spimdev.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include
+#include
+#include
+#include
+#include
+
+struct spimdev_mdev_state {
+ struct vfio_spimdev *spimdev;
+};
+
+static struct class *spimdev_class;
+static DEFINE_IDR(spimdev_idr);
+
+static int vfio_spimdev_dev_exist(struct device *dev, void *data)
+{
+ return !strcmp(dev_name(dev), dev_name((struct device *)data));
+}
+
+#ifdef CONFIG_IOMMU_SVA
+static bool vfio_spimdev_is_valid_pasid(int pasid)
+{
+ struct mm_struct *mm;
+
+ mm = iommu_sva_find(pasid);
+ if (mm) {
+ mmput(mm);
+ return mm == current->mm;
+ }
+
+ return false;
+}
+#endif
+
+/* Check if the device is a mediated device belongs to vfio_spimdev */
+int vfio_spimdev_is_spimdev(struct device *dev)
+{
+ struct mdev_device *mdev;
+ struct device *pdev;
+
+ mdev = mdev_from_dev(dev);
+ if (!mdev)
+ return 0;
+
+ pdev = mdev_parent_dev(mdev);
+ if (!pdev)
+ return 0;
+
+ return class_for_each_device(spimdev_class, NULL, pdev,
+ vfio_spimdev_dev_exist);
+}
+EXPORT_SYMBOL_GPL(vfio_spimdev_is_spimdev);
+
+struct vfio_spimdev *vfio_spimdev_pdev_spimdev(struct device *dev)
+{
+ struct device *class_dev;
+
+ if (!dev)
+ return ERR_PTR(-EINVAL);
+
+ class_dev = class_find_device(spimdev_class, NULL, dev,
+ (int(*)(struct device *, const void *))vfio_spimdev_dev_exist);
+ if (!class_dev)
+ return ERR_PTR(-ENODEV);
+
+ return container_of(class_dev, struct vfio_spimdev, cls_dev);
+}
+EXPORT_SYMBOL_GPL(vfio_spimdev_pdev_spimdev);
+
+struct vfio_spimdev *mdev_spimdev(struct mdev_device *mdev)
+{
+ struct device *pdev = mdev_parent_dev(mdev);
+
+ return vfio_spimdev_pdev_spimdev(pdev);
+}
+EXPORT_SYMBOL_GPL(mdev_spimdev);
+
+static ssize_t iommu_type_show(struct device *dev,
+
[RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive framework
From: Kenneth Lee WarpDrive is a common user space accelerator framework. Its main component in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes the hardware capabilities to the user space via vfio-mdev. So processes in user land can obtain a "queue" by open the device and direct access the hardware MMIO space or do DMA operation via VFIO interface. WarpDrive is intended to be used with Jean Philippe Brucker's SVA patchset (it is still in RFC stage) to support multi-process. But This is not a must. Without the SVA patches, WarpDrive can still work for one process for every hardware device. This patch add detail documents for the framework. Signed-off-by: Kenneth Lee --- Documentation/00-INDEX| 2 + Documentation/warpdrive/warpdrive.rst | 153 ++ Documentation/warpdrive/wd-arch.svg | 732 ++ Documentation/warpdrive/wd.svg| 526 ++ 4 files changed, 1413 insertions(+) create mode 100644 Documentation/warpdrive/warpdrive.rst create mode 100644 Documentation/warpdrive/wd-arch.svg create mode 100644 Documentation/warpdrive/wd.svg diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 2754fe83f0d4..9959affab599 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -410,6 +410,8 @@ vm/ - directory with info on the Linux vm code. w1/ - directory with documents regarding the 1-wire (w1) subsystem. +warpdrive/ + - directory with documents about WarpDrive accelerator framework. watchdog/ - how to auto-reboot Linux if it has "fallen and can't get up". ;-) wimax/ diff --git a/Documentation/warpdrive/warpdrive.rst b/Documentation/warpdrive/warpdrive.rst new file mode 100644 index ..3792b2780ea6 --- /dev/null +++ b/Documentation/warpdrive/warpdrive.rst @@ -0,0 +1,153 @@ +Introduction of WarpDrive += + +*WarpDrive* is a general accelerator framework built on top of vfio. +It can be taken as a light weight virtual function, which you can use without +*SR-IOV* like facility and can be shared among multiple processes. + +It can be used as the quick channel for accelerators, network adaptors or +other hardware in user space. It can make some implementation simpler. E.g. +you can reuse most of the *netdev* driver and just share some ring buffer to +the user space driver for *DPDK* or *ODP*. Or you can combine the RSA +accelerator with the *netdev* in the user space as a Web reversed proxy, etc. + +The name *WarpDrive* is simply a cool and general name meaning the framework +makes the application faster. In kernel, the framework is called SPIMDEV, +namely "Share Parent IOMMU Mediated Device". + + +How does it work + + +*WarpDrive* takes the Hardware Accelerator as a heterogeneous processor which +can share some load for the CPU: + +.. image:: wd.svg +:alt: This is a .svg image, if your browser cannot show it, +try to download and view it locally + +So it provides the capability to the user application to: + +1. Send request to the hardware +2. Share memory with the application and other accelerators + +These requirements can be fulfilled by VFIO if the accelerator can serve each +application with a separated Virtual Function. But a *SR-IOV* like VF (we will +call it *HVF* hereinafter) design is too heavy for the accelerator which +service thousands of processes. + +And the *HVF* is not good for the scenario that a device keep most of its +resource but share partial of the function to the user space. E.g. a *NIC* +works as a *netdev* but share some hardware queues to the user application to +send packets direct to the hardware. + +*VFIO-mdev* can solve some of the problem here. But *VFIO-mdev* has two problem: + +1. it cannot make use of its parent device's IOMMU. +2. it is assumed to be openned only once. + +So it will need some add-on for better resource control and let the VFIO +driver be aware of this. + + +Architecture + + +The full *WarpDrive* architecture is represented in the following class +diagram: + +.. image:: wd-arch.svg +:alt: This is a .svg image, if your browser cannot show it, +try to download and view it locally + +The idea is: when a device is probed, it can be registered to the general +framework, e.g. *netdev* or *crypto*, and the *SPIMDEV* at the same time. + +If *SPIMDEV* is registered. A *mdev* creation interface is created. Then the +system administrator can create a *mdev* in the user space and set its +parameters via its sysfs interfacev. But not like the other mdev +implementation, hardware resource will not be allocated until it is opened by +an application. + +With this strategy, the hardware resource can be easily scheduled among +multiple processes. + + +The user API + + +We adopt a polling style interface in the user space: :: + +int wd_request_queue(int container, struct wd_queue *q, +
[RFC PATCH 0/7] A General Accelerator Framework, WarpDrive
From: Kenneth Lee WarpDrive is an accelerator framework to expose the hardware capabilities directly to the user space. It makes use of the exist vfio and vfio-mdev facilities. So the user application can send request and DMA to the hardware without interaction with the kernel. This remove the latency of syscall and context switch. The patchset contains documents for the detail. Please refer to it for more information. This patchset is intended to be used with Jean Philippe Brucker's SVA patch [1] (Which is also in RFC stage). But it is not mandatory. This patchset is tested in the latest mainline kernel without the SVA patches. So it support only one process for each accelerator. With SVA support, WarpDrive can support multi-process in the same accelerator device. We tested it in our SoC integrated Accelerator (board ID: D06, Chip ID: HIP08). A reference work tree can be found here: [2]. We have noticed the IOMMU aware mdev RFC announced recently [3]. The IOMMU aware mdev has similar idea but different intention comparing to WarpDrive. It intends to dedicate part of the hardware resource to a VM. And the design is supposed to be used with Scalable I/O Virtualization. While spimdev is intended to share the hardware resource with a big amount of processes. It just requires the hardware supporting address translation per process (PCIE's PASID or ARM SMMU's substream ID). But we don't see serious confliction on both design. We believe they can be normalized as one. The patch 1 is document. The patch 2 and 3 add spimdev support. The patch 4, 5 and 6 is drivers for Hislicon's ZIP Accelerator which is registered to both crypto and warpdrive(spimdev) and can be used from kernel or user space at the same time. The patch 7 is a user space sample demonstrating how WarpDrive works. Refernces: [1] https://www.spinics.net/lists/kernel/msg2651481.html [2] https://github.com/Kenneth-Lee/linux-kernel-warpdrive/tree/warpdrive-sva-v0.5 [3] https://lkml.org/lkml/2018/7/22/34 Best Regards Kenneth Lee Kenneth Lee (7): vfio/spimdev: Add documents for WarpDrive framework iommu: Add share domain interface in iommu for spimdev vfio: add spimdev support crypto: add hisilicon Queue Manager driver crypto: Add Hisilicon Zip driver crypto: add spimdev support to Hisilicon QM vfio/spimdev: add user sample for spimdev Documentation/00-INDEX|2 + Documentation/warpdrive/warpdrive.rst | 153 Documentation/warpdrive/wd-arch.svg | 732 +++ Documentation/warpdrive/wd.svg| 526 +++ drivers/crypto/Kconfig|2 + drivers/crypto/Makefile |1 + drivers/crypto/hisilicon/Kconfig | 15 + drivers/crypto/hisilicon/Makefile |2 + drivers/crypto/hisilicon/qm.c | 1005 + drivers/crypto/hisilicon/qm.h | 123 +++ drivers/crypto/hisilicon/zip/Makefile |2 + drivers/crypto/hisilicon/zip/zip.h| 55 ++ drivers/crypto/hisilicon/zip/zip_crypto.c | 358 drivers/crypto/hisilicon/zip/zip_crypto.h | 18 + drivers/crypto/hisilicon/zip/zip_main.c | 182 drivers/iommu/iommu.c | 28 +- drivers/vfio/Kconfig |1 + drivers/vfio/Makefile |1 + drivers/vfio/spimdev/Kconfig | 10 + drivers/vfio/spimdev/Makefile |3 + drivers/vfio/spimdev/vfio_spimdev.c | 421 + drivers/vfio/vfio_iommu_type1.c | 136 ++- include/linux/iommu.h |2 + include/linux/vfio_spimdev.h | 95 ++ include/uapi/linux/vfio_spimdev.h | 28 + samples/warpdrive/AUTHORS |2 + samples/warpdrive/ChangeLog |1 + samples/warpdrive/Makefile.am |9 + samples/warpdrive/NEWS|1 + samples/warpdrive/README | 32 + samples/warpdrive/autogen.sh |3 + samples/warpdrive/cleanup.sh | 13 + samples/warpdrive/configure.ac| 52 ++ samples/warpdrive/drv/hisi_qm_udrv.c | 223 + samples/warpdrive/drv/hisi_qm_udrv.h | 53 ++ samples/warpdrive/test/Makefile.am|7 + samples/warpdrive/test/comp_hw.h | 23 + samples/warpdrive/test/test_hisi_zip.c| 204 + samples/warpdrive/wd.c| 325 +++ samples/warpdrive/wd.h| 153 samples/warpdrive/wd_adapter.c| 74 ++ samples/warpdrive/wd_adapter.h| 43 + 42 files changed, 5112 insertions(+), 7 deletions(-) create mode 100644 Documentation/warpdrive/warpdrive.rst create mode 100644 Documentation/warpdrive/wd-arch.svg create mode 100644 Documentation/warpdrive/wd.svg create mode 100644 drivers/crypto/hisilicon/Kconfig create mode 100644 drivers/crypto/hisilicon/Makefile create mode 100644
Re: [PATCH] ia64: fix barrier placement for write* / dma mapping
On 8/1/2018 12:29 AM, Christoph Hellwig wrote: I asked this question to Tony Luck before. If I remember right, his answer was: CPU guarantees outstanding writes to be flushed when a register write instruction is executed and an additional barrier instruction is not needed. That would be great. It still doesn't explain the barriers in the dma sync routines. Those have been there since the following commit in the history tree: Yeah, I'll let Tony confirm my understanding. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] ia64: fix barrier placement for write* / dma mapping
On Tue, Jul 31, 2018 at 11:41:23PM -0700, ok...@codeaurora.org wrote: > I asked this question to Tony Luck before. If I remember right, > his answer was: > > CPU guarantees outstanding writes to be flushed when a register write > instruction is executed and an additional barrier instruction is not > needed. That would be great. It still doesn't explain the barriers in the dma sync routines. Those have been there since the following commit in the history tree: commit 66b99421d118a5ddd98a72913670b0fcf0a38d45 Author: Andrew Morton Date: Sat Mar 13 17:05:37 2004 -0800 [PATCH] DMA: Fill gaping hole in DMA API interfaces. From: "David S. Miller" which in fact only added them for the HP zx1 platform, and doesn't contain any good explanation of why we need a barrier. So I guess the right answer might be to just remove these barriers without replacement. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] ia64: fix barrier placement for write* / dma mapping
+ my new email On 2018-07-31 10:20, Christoph Hellwig wrote: memory-barriers.txt has been updated with the following requirement. "When using writel(), a prior wmb() is not needed to guarantee that the cache coherent memory writes have completed before writing to the MMIO region." The current writeX() and iowriteX() implementations on ia64 are not satisfying this requirement as the barrier is after the register write. I asked this question to Tony Luck before. If I remember right, his answer was: CPU guarantees outstanding writes to be flushed when a register write instruction is executed and an additional barrier instruction is not needed. This adds the missing memory barriers, and instead drops them from the dma sync routine where they are misplaced (and were missing in the more important map/unmap cases anyway). All this doesn't affect the SN2 platform, which already has barrier in the I/O accessors, and none in dma mapping (but then again swiotlb doesn't have any either). Signed-off-by: Christoph Hellwig --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
