Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1697587imm; Wed, 1 Aug 2018 22:39:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpff5FPjhNBwrNxzrocf8FEdpH7NQk6k574yAUtjYxQyCA2ewXiF07J8G5wglpS3fNwP6iIE X-Received: by 2002:a63:c80e:: with SMTP id z14-v6mr1283179pgg.77.1533188363108; Wed, 01 Aug 2018 22:39:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533188363; cv=none; d=google.com; s=arc-20160816; b=NZB6qkcxuMk5dDmma11DW0maGUj9Sg55BcjIMGG5Jga9P+0h2jWpOD0z96wavqNSwS 4sOF9NFYQs15ZtXBc8PhBWm6zRGOPRSdpyhWNzSMaSlkPjV2GCGFUY3uCJeYuLrrVoyx 49+pxcGPckLOotlaBt/lmBuIFHvFhRA7gvp9cecIzcl01AQoXa7JeMZdrmbPd6f/UihA dK0LuXfXHHqbZ5mDjwJMgvLB+f0wlbqWUqaQlke8PxA3JtYuOTmmJ8y6OXLGeI+jViit 9mSkZcXsMytZ1MH+/sMF+fmHe/u9uh9xNSeMxUpOHfOY9eKlq3btEafZ2IoGlFZqsEuf NkTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=FAkUgjtcV5EXKReo7ugcMLlGv08Q1kle2jiteF3ft+c=; b=wCZtWEWPh2xNVXDP2I8GiqRtgzbYt2YJjQTfGRUZf2SkyuA6lPrVA073Z1SuUq5E2s VFBVmZkZp/n6KBzSnTud4V03uePMPIhNRFQt5ja8ngVmjMpOtwbP+jAHQ3bWAQxZUaxI NWVShPx8UVaR26kv2giKZ9WO90P2YZ0aGVqC9C8AM2e8c8PL2jtKPVmTnTKuO5qbocbF GlS45PumCula2p3GWop99FhQGTDviZMp3z7fZxnTHoOZmbsKrT+j969Iz4t56T++UQMQ kagOclXZNN+kA4BZtOiRk7KWgGvsJotqh/q0ziGpDTXlBh/4IMeBl01QMpB1D8TdkqV7 2AQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s85-v6si1058395pfe.290.2018.08.01.22.38.54; Wed, 01 Aug 2018 22:39:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726217AbeHBH0y (ORCPT + 99 others); Thu, 2 Aug 2018 03:26:54 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:42597 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725954AbeHBH0y (ORCPT ); Thu, 2 Aug 2018 03:26:54 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 354B3FD63C14B; Thu, 2 Aug 2018 13:37:26 +0800 (CST) Received: from localhost (10.67.212.75) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 2 Aug 2018 13:37:17 +0800 Date: Thu, 2 Aug 2018 13:35:58 +0800 From: Kenneth Lee To: "Tian, Kevin" CC: Kenneth Lee , Herbert Xu , "kvm@vger.kernel.org" , Jonathan Corbet , Greg Kroah-Hartman , "linux-doc@vger.kernel.org" , "Kumar, Sanjay K" , Hao Fang , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linuxarm@huawei.com" , Alex Williamson , Thomas Gleixner , "linux-crypto@vger.kernel.org" , Philippe Ombredanne , Zaibo Xu , "David S . Miller" , "linux-accelerators@lists.ozlabs.org" Subject: Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive Message-ID: <20180802053558.GO160746@Turing-Arch-b> References: <20180801102221.5308-1-nek.in.cn@gmail.com> <20180802034006.GJ160746@Turing-Arch-b> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 02, 2018 at 04:36:52AM +0000, Tian, Kevin wrote: > Date: Thu, 2 Aug 2018 04:36:52 +0000 > From: "Tian, Kevin" > To: Kenneth Lee > CC: Kenneth Lee , Herbert Xu > , "kvm@vger.kernel.org" > , Jonathan Corbet , Greg > Kroah-Hartman , "linux-doc@vger.kernel.org" > , "Kumar, Sanjay K" , > Hao Fang , "iommu@lists.linux-foundation.org" > , "linux-kernel@vger.kernel.org" > , "linuxarm@huawei.com" > , Alex Williamson , > Thomas Gleixner , "linux-crypto@vger.kernel.org" > , Philippe Ombredanne > , Zaibo Xu , "David S . Miller" > , "linux-accelerators@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 +0000, 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!