RE: Support SVM without PASID

2017-08-03 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, August 1, 2017 4:26 PM > > It depends what type you use when registering the IOMMU with > VFIO_SET_IOMMU: > > * If the type is VFIO_TYPE1v2_IOMMU, then > VFIO_IOMMU_MAP/UNMAP_DMA > affects the stage-1 non-PASID context (already the case in

RE: Support SVM without PASID

2017-08-11 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Friday, August 4, 2017 5:43 PM > > Hi Kevin, > > On 04/08/17 02:49, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Tuesday, August 1, 2017 4:26 PM > >> >

RE: Support SVM without PASID

2017-08-11 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Monday, August 7, 2017 8:52 PM > > Hi Bob, > > On 07/08/17 13:18, Bob Liu wrote: > > On 2017/8/7 18:31, Jean-Philippe Brucker wrote: > >> On 05/08/17 06:14, valmiki wrote: > >> [...] > >>> Hi Jean, Thanks a lot, now i

RE: Support SVM without PASID

2017-08-14 Thread Tian, Kevin
> From: Raj, Ashok > Sent: Saturday, August 12, 2017 12:25 AM > > On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote: > > Hi Kevin, > > > > > > Consider the situation where a userspace driver (no virtualization) is > > built in a client-server fashion: the server controls a

RE: [RFC] virtio-iommu version 0.4

2017-08-14 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, August 5, 2017 2:19 AM > > This is the continuation of my proposal for virtio-iommu, the para- > virtualized IOMMU. Here is a summary of the changes since last time [1]: > > * The virtio-iommu document now

RE: Support SVM without PASID

2017-08-14 Thread Tian, Kevin
> From: valmiki [mailto:valmiki...@gmail.com] > Sent: Saturday, August 12, 2017 8:11 PM > > On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote: > > On 05/08/17 06:14, valmiki wrote: > > [...] > >> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel > >> documentation we fill vaddr

RE: [PATCH 2/9] iommu/vt-d: add bind_pasid_table function

2017-07-05 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Wednesday, June 28, 2017 3:48 AM > > Add Intel VT-d ops to the generic iommu_bind_pasid_table API > functions. > > The primary use case is for direct assignment of SVM capable > device. Originated from emulated IOMMU in the guest,

RE: [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

2017-07-04 Thread Tian, Kevin
> From: Liu, Yi L [mailto:yi.l@linux.intel.com] > Sent: Sunday, May 14, 2017 6:55 PM > > On Fri, May 12, 2017 at 03:58:43PM -0600, Alex Williamson wrote: > > On Wed, 26 Apr 2017 18:12:04 +0800 > > "Liu, Yi L" wrote: > > > > > From: "Liu, Yi L" >

RE: [PATCH 3/9] iommu: Introduce iommu do invalidate API function

2017-07-05 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, June 29, 2017 1:08 AM > > On 28/06/17 17:09, Jacob Pan wrote: > > On Wed, 28 Jun 2017 12:08:23 +0200 > > Joerg Roedel wrote: > > > >> On Tue, Jun 27, 2017 at 12:47:57PM -0700, Jacob Pan wrote:

RE: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

2017-07-05 Thread Tian, Kevin
> From: Liu, Yi L > Sent: Monday, July 3, 2017 6:31 PM > > Hi Jean, > > > > > > > 2. Define a structure in include/uapi/linux/iommu.h(newly added header > file) > > > > > > struct iommu_tlb_invalidate { > > > __u32 scope; > > > /* pasid-selective invalidation described by @pasid */ > > >

RE: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

2017-07-05 Thread Tian, Kevin
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, July 6, 2017 1:28 AM > > On Wed, 5 Jul 2017 13:42:03 +0100 > Jean-Philippe Brucker <jean-philippe.bruc...@arm.com> wrote: > > > On 05/07/17 07:45, Tian, Kevin wrote: > > >> F

RE: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

2017-07-05 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Wednesday, July 5, 2017 8:42 PM > > On 05/07/17 07:45, Tian, Kevin wrote: > >> From: Liu, Yi L > >> Sent: Monday, July 3, 2017 6:31 PM > >> > >> Hi Jean, > >> > >> > >>> > >&g

RE: [Qemu-devel] [RFC PATCH 09/20] Memory: introduce iommu_ops->record_device

2017-05-19 Thread Tian, Kevin
> From: Liu, Yi L [mailto:yi.l@linux.intel.com] > Sent: Friday, May 19, 2017 1:24 PM > > Hi Alex, > > What's your opinion with Tianyu's question? Is it accepatable > to use VFIO API in intel_iommu emulator? Did you actually need such translation at all? SID should be filled by kernel IOMMU

RE: [RFC] virtio-iommu version 0.4

2017-09-21 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Wednesday, September 6, 2017 7:55 PM > > Hi Kevin, > > On 28/08/17 08:39, Tian, Kevin wrote: > > Here comes some comments: > > > > 1.1 Motivation > > > > You describe I/O page faults handling as future work. S

RE: bind pasid table API

2017-09-28 Thread Tian, Kevin
> From: Raj, Ashok > Sent: Friday, September 29, 2017 1:11 AM > > Hi Jean > > On Thu, Sep 28, 2017 at 12:21:34PM +0100, Jean-Philippe Brucker wrote: > > On 27/09/17 14:40, Joerg Roedel wrote: > > > Hi, > > > > > > On Wed, Sep 20, 2017 at 01:09:47PM +0100, Jean-Philippe Brucker > wrote: > > >>

RE: [RFC 2/3] virtio-iommu: device probing and operations

2017-08-21 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Monday, April 24, 2017 11:06 PM > 1. Attach device > > > struct virtio_iommu_req_attach { > le32address_space; > le32device; > le32flags/reserved; >

RE: [RFC 2/3] virtio-iommu: device probing and operations

2017-08-22 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Monday, August 21, 2017 8:00 PM > > On 21/08/17 08:59, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > >> Sent: Monday, April 24, 2017 11:06

RE: [RFC] virtio-iommu version 0.4

2017-08-28 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, August 23, 2017 6:01 PM > > On 04/08/17 19:19, Jean-Philippe Brucker wrote: > > Other extensions are in preparation. I won't detail them here because > v0.4 > > already is a lot to digest, but in short,

RE: Support SVM without PASID

2017-08-28 Thread Tian, Kevin
> From: Bharat Kumar Gogada [mailto:bhara...@xilinx.com] > Sent: Monday, August 28, 2017 9:10 PM > > > Subject: RE: Support SVM without PASID > > > > > From: valmiki [mailto:valmiki...@gmail.com] > > > Sent: Saturday, August 12, 2017 8:11 PM > > > > > > On 8/7/2017 4:01 PM, Jean-Philippe Brucker

RE: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

2018-02-12 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, February 13, 2018 2:33 AM > > Add bind() and unbind() operations to the IOMMU API. Device drivers can > use them to share process page tables with their devices. bind_group() > is provided for VFIO's convenience, as it needs to provide a coherent >

RE: [PATCH 04/37] iommu/sva: Add a mm_exit callback for device drivers

2018-02-13 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, February 13, 2018 2:33 AM > > When an mm exits, devices that were bound to it must stop performing > DMA > on its PASID. Let device drivers register a callback to be notified on mm > exit. Add the callback to the iommu_param structure attached to

RE: [PATCH 01/37] iommu: Introduce Shared Virtual Addressing API

2018-02-12 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, February 13, 2018 2:33 AM > > Shared Virtual Addressing (SVA) provides a way for device drivers to bind > process address spaces to devices. This requires the IOMMU to support the > same page table format as CPUs, and requires the system to support

RE: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

2018-02-13 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, February 13, 2018 8:57 PM > > On 13/02/18 07:54, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Tuesday, February 13, 2018 2:33 AM > >> > >> Add bind() and unbind() operations to t

RE: [PATCH 01/37] iommu: Introduce Shared Virtual Addressing API

2018-02-13 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Tuesday, February 13, 2018 8:40 PM > > > [...] > >> + > >> +/** > >> + * iommu_sva_device_init() - Initialize Shared Virtual Addressing for a > >> device > >> + * @dev: the device > >> + * @features: bitmask of features that need to be initialized > >> + *

RE: [PATCH 01/37] iommu: Introduce Shared Virtual Addressing API

2018-02-26 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, February 15, 2018 8:42 PM > > On 13/02/18 23:43, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Tues

RE: Question on IOMMU indentity mapping for intel-iommu

2018-02-28 Thread Tian, Kevin
> From: David Woodhouse > Sent: Tuesday, February 27, 2018 3:48 PM > > On Mon, 2018-02-26 at 15:01 -0800, Alexander Duyck wrote: > > I am interested in adding a new memory mapping option that > > establishes > > one identity-mapped region for all DMA_TO_DEVICE mappings and > creates > > a new

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

2018-03-19 Thread Tian, Kevin
> From: Shameerali Kolothum Thodi > [mailto:shameerali.kolothum.th...@huawei.com] > > Hi Kevin, > > Thanks for taking a look at this series. > > > -Original Message- > > From: Tian, Kevin [mailto:kevin.t...@intel.com] > > Sent: Monday, March 19, 2

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

2018-03-19 Thread Tian, Kevin
> From: Shameerali Kolothum Thodi > [mailto:shameerali.kolothum.th...@huawei.com] > > > -Original Message- > > From: Tian, Kevin [mailto:kevin.t...@intel.com] > > Sent: Monday, March 19, 2018 7:52 AM > > To: Shameerali Kolothum Thodi > &

RE: [PATCH 1/4] iommu: Add virtio-iommu driver

2018-03-22 Thread Tian, Kevin
> From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Wednesday, March 21, 2018 10:24 PM > > On 21/03/18 13:14, Jean-Philippe Brucker wrote: > > On 21/03/18 06:43, Tian, Kevin wrote: > > [...] > >>> + > >>> +#include > >>>

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

2018-03-22 Thread Tian, Kevin
> From: Alex Williamson > Sent: Thursday, March 22, 2018 1:11 AM > > On Wed, 21 Mar 2018 03:28:16 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, March

RE: [PATCH 1/4] iommu: Add virtio-iommu driver

2018-03-21 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

2018-03-20 Thread Tian, Kevin
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, March 21, 2018 6:55 AM > > On Mon, 19 Mar 2018 08:28:32 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Shameer Kolothum > > > Sent: Friday, March

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

2018-03-20 Thread Tian, Kevin
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, March 21, 2018 6:38 AM > > On Mon, 19 Mar 2018 07:51:58 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Shameer Kolothum > > > Sent: Friday

RE: [PATCH 1/4] iommu: Add virtio-iommu driver

2018-03-23 Thread Tian, Kevin
> From: Tian, Kevin > Sent: Thursday, March 22, 2018 6:06 PM > > > From: Robin Murphy [mailto:robin.mur...@arm.com] > > Sent: Wednesday, March 21, 2018 10:24 PM > > > > On 21/03/18 13:14, Jean-Philippe Brucker wrote: > >

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

2018-03-19 Thread Tian, Kevin
> From: Shameer Kolothum > Sent: Friday, March 16, 2018 12:35 AM > > This retrieves the reserved regions associated with dev group and > checks for conflicts with any existing dma mappings. Also update > the iova list excluding the reserved regions. > > Signed-off-by: Shameer Kolothum >

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

2018-03-19 Thread Tian, Kevin
> From: Shameer Kolothum > Sent: Friday, March 16, 2018 12:35 AM > > This series introduces an iova list associated with a vfio > iommu. The list is kept updated taking care of iommu apertures, > and reserved regions. Also this series adds checks for any conflict > with existing dma mappings

RE: [PATCH v3 02/10] iommu/sva: Bind process address spaces to devices

2018-09-27 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, September 27, 2018 11:06 PM > > On 26/09/2018 19:01, Jacob Pan wrote: > > On Mon, 24 Sep 2018 13:07:47 +0100 > > Jean-Philippe Brucker wrote: > > > >> On 23/09/2018 04:05, Lu Baolu wrote: > >> > Hi, > >> > >

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-10-22 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, October 20, 2018 2:12 AM > > This is a first prototype adding auxiliary domain support to Arm SMMUv3, > following Lu Baolu's latest proposal for IOMMU aware mediated devices > [1]. It works, but the attach()

RE: [RFC PATCH 2/6] drivers core: Add I/O ASID allocator

2018-10-23 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, October 23, 2018 2:57 PM > > Hi, > > On 10/22/18 6:22 PM, Raj, Ashok wrote: > > On Mon, Oct 22, 2018 at 12:49:47PM +0800, Lu Baolu wrote: > >> Hi, > >> > >> On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote: > >>> Some devices

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-10-23 Thread Tian, Kevin
> From: Raj, Ashok > Sent: Wednesday, October 24, 2018 1:17 AM > > > > > But that's not reason enough to completely disable PASID for the > > device, > > it could be the only one bound to that process, or PASID could be > > only > > used privately by the host device driver. > > Agree, there

RE: [RFC 01/13] iommu: Introduce bind_guest_stage API

2018-09-04 Thread Tian, Kevin
> From: Auger Eric > Sent: Tuesday, September 4, 2018 4:11 PM > > Hi Kevin, > On 09/04/2018 09:57 AM, Tian, Kevin wrote: > >> From: Auger Eric > >> Sent: Friday, August 31, 2018 9:52 PM > >> > >> Hi Jean-Philippe, > >> > >&g

RE: [RFC 01/13] iommu: Introduce bind_guest_stage API

2018-09-04 Thread Tian, Kevin
> From: Auger Eric > Sent: Friday, August 31, 2018 9:52 PM > > Hi Jean-Philippe, > > On 08/31/2018 03:11 PM, Jean-Philippe Brucker wrote: > > Hi Eric, > > > > On 23/08/18 16:25, Auger Eric wrote: > >>> +int iommu_bind_guest_stage(struct iommu_domain *domain, struct > device *dev, > >>> +

RE: [RFC 01/13] iommu: Introduce bind_guest_stage API

2018-09-04 Thread Tian, Kevin
> From: Auger Eric > Sent: Tuesday, September 4, 2018 4:41 PM > > Hi Kevin, > > On 09/04/2018 10:34 AM, Tian, Kevin wrote: > >> From: Auger Eric > >> Sent: Tuesday, September 4, 2018 4:11 PM > >> > >> Hi Kevin, > >> On 09/04/2018 0

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-12-12 Thread Tian, Kevin
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org] > Sent: Wednesday, December 12, 2018 5:54 PM > > Hi Kevin, > > On Wed, Dec 12, 2018 at 09:31:27AM +, Tian, Kevin wrote: > > > From: 'j...@8bytes.org' > > > Sent: Monday, December 10, 2018 4:58 PM >

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-12-12 Thread Tian, Kevin
> From: 'j...@8bytes.org' > Sent: Monday, December 10, 2018 4:58 PM > > Hi Kevin, > > On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote: > > Can I interpret above as that you agree with the aux domain concept (i.e. > one > > device can be linked to mult

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-12-09 Thread Tian, Kevin
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org] > Sent: Friday, December 7, 2018 6:29 PM > > Hi, > > On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote: > > btw Baolu just reminded me one thing which is worthy of noting here. > > 'primary' vs. 'aux' co

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-11-25 Thread Tian, Kevin
> From: Tian, Kevin > Sent: Monday, November 26, 2018 11:01 AM [...] > > aux-domain is just a normal domain (struct iommu_domain), what > > happens > > when a domain that was used as a primary domain and has bound > > aux-domains to it, is bound with iommu_aux_domain_

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-11-25 Thread Tian, Kevin
> From: j...@8bytes.org [mailto:j...@8bytes.org] > Sent: Friday, November 23, 2018 7:21 PM > > On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote: > > Can you please elaborate a bit more about the concept of subdomains? > > From my point of view, an aux-domain is a normal un-managed domain

RE: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-11-22 Thread Tian, Kevin
> From: j...@8bytes.org [mailto:j...@8bytes.org] > Sent: Monday, November 12, 2018 10:56 PM > > Hi Jean-Philippe, > > On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote: > > (1) My initial approach would have been to use the same page tables for > > the default_domain and this

RE: [RFC PATCH 2/6] drivers core: Add I/O ASID allocator

2018-11-21 Thread Tian, Kevin
> From: Koenig, Christian > Sent: Thursday, November 22, 2018 3:10 AM > > Am 21.11.18 um 12:16 schrieb Jean-Philippe Brucker: > > On 12/11/2018 14:40, Joerg Roedel wrote: > >> Hi Jean-Philippe, > >> > >> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote: > >>> The allocator

RE: [RFC PATCH v2 00/10] vfio/mdev: IOMMU aware mediated device

2018-09-12 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Thursday, September 13, 2018 1:54 AM > > On 12/09/2018 03:42, Lu Baolu wrote: > > Hi, > > > > On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote: > >> Hi, > >> > >> On 30/08/2018 05:09, Lu Baolu wrote: > >>> Below APIs are introduced in the IOMMU glue for

RE: [RFC PATCH v2 08/10] vfio/type1: Add domain at(de)taching group helpers

2018-09-12 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, September 13, 2018 1:54 AM > > On 12/09/2018 06:02, Lu Baolu wrote: > > Hi, > > > > On 09/11/2018 12:23 AM, Jean-Philippe Brucker wrote: > >> On 30/08/2018 05:09, Lu Baolu wrote: > >>> +static int

RE: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

2018-09-13 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Saturday, September 8, 2018 5:25 AM > > > iommu-sva expects everywhere that the device has an iommu_domain, > > > it's the first thing we check on entry. Bypassing all of this would > > > call idr_alloc() directly, and wouldn't have

RE: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API

2018-09-13 Thread Tian, Kevin
> From: Christian König > Sent: Friday, September 7, 2018 4:56 PM > > 5. It would be nice to have to allocate multiple PASIDs for the same > process address space. >         E.g. some teams at AMD want to use a separate GPU address space > for their userspace client library. I'm still trying to

RE: [PATCH v2 06/12] iommu/vt-d: Add second level page table interface

2018-09-12 Thread Tian, Kevin
> From: Raj, Ashok > Sent: Saturday, September 8, 2018 1:43 AM > > On Fri, Sep 07, 2018 at 10:47:11AM +0800, Lu Baolu wrote: > > > > >>+ > > >>+ intel_pasid_clear_entry(dev, pasid); > > >>+ > > >>+ if (!ecap_coherent(iommu->ecap)) { > > >>+ pte = intel_pasid_get_entry(dev, pasid); > > >>+

RE: [RFC PATCH v2 08/10] vfio/type1: Add domain at(de)taching group helpers

2018-09-14 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Friday, September 14, 2018 10:46 PM > > On 13/09/2018 01:35, Tian, Kevin wrote: > >>> Let's consider it from the API point of view. > >>> > >>> We have iommu_a(de)ttach_device() APIs to attach or detach

RE: [RFC PATCH v2 00/10] vfio/mdev: IOMMU aware mediated device

2018-09-13 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, September 13, 2018 11:03 PM > > On 13/09/2018 01:19, Tian, Kevin wrote: > >>> This is proposed for architectures which support finer granularity > >>> second level transla

RE: [RFC PATCH v2 00/10] vfio/mdev: IOMMU aware mediated device

2018-09-13 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Friday, September 14, 2018 10:47 AM > > Hi, > > On 09/13/2018 01:54 AM, Jean-Philippe Brucker wrote: > > On 12/09/2018 03:42, Lu Baolu wrote: > >> Hi, > >> > >> On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote: > >>> Hi, > >>> > >>>

RE: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive

2018-09-14 Thread Tian, Kevin
> From: Jerome Glisse > Sent: Thursday, September 13, 2018 10:52 PM > [...] > AFAIK, on x86 and PPC at least, all PCIE devices are in the same group > by default at boot or at least all devices behind the same bridge. the group thing reflects physical hierarchy limitation, not changed cross

RE: [RFC PATCH v2 08/10] vfio/type1: Add domain at(de)taching group helpers

2018-09-18 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Tuesday, September 18, 2018 11:52 PM > > On 15/09/2018 03:36, Tian, Kevin wrote: > >> 4) Userspace opens another mdev. > >> -> iommu.c calls domain->ops->attach_dev(domain2,

RE: [RFC PATCH v2 00/10] vfio/mdev: IOMMU aware mediated device

2018-09-18 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Tuesday, September 18, 2018 11:47 PM > > On 14/09/2018 22:04, Jacob Pan wrote: > >> This example only needs to modify first-level translation, and works > >> with SMMUv3. The kernel here could be the host, in which case

RE: [PATCH v3 02/16] iommu: Introduce cache_invalidate API

2019-05-15 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Wednesday, May 15, 2019 7:04 PM > > On 14/05/2019 18:44, Jacob Pan wrote: > > Hi Thank you both for the explanation. > > > > On Tue, 14 May 2019 11:41:24 +0100 > > Jean-Philippe Brucker wrote: > > > >> On 14/05/2019 08:36, Auger Eric wrote: > >>> Hi Jacob, >

RE: [PATCH v2 2/4] iommu: Introduce device fault data

2019-06-05 Thread Tian, Kevin
> From: Jacob Pan > Sent: Tuesday, June 4, 2019 6:09 AM > > On Mon, 3 Jun 2019 15:57:47 +0100 > Jean-Philippe Brucker wrote: > > > +/** > > + * struct iommu_fault_page_request - Page Request data > > + * @flags: encodes whether the corresponding fields are valid and > > whether this > > + *

RE: [PATCH v2 2/4] iommu: Introduce device fault data

2019-06-06 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Thursday, June 6, 2019 1:38 AM > > On Wed, 5 Jun 2019 08:51:45 +0000 > "Tian, Kevin" wrote: > > > > From: Jacob Pan > > > Sent: Tuesday, June 4, 2019 6:09 AM > > > >

RE: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest

2019-09-24 Thread Tian, Kevin
> From: Raj, Ashok > Sent: Tuesday, September 24, 2019 4:26 AM > > Hi Jacob > > On Mon, Sep 23, 2019 at 12:27:15PM -0700, Jacob Pan wrote: > > > > > > In VT-d 3.0, scalable mode is introduced, which offers two level > > > translation page tables and nested translation mode. Regards to > > >

RE: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)

2019-10-25 Thread Tian, Kevin
> From: Liu Yi L > Sent: Thursday, October 24, 2019 8:26 PM > > This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims > to passdown PASID allocation/free request from the virtual > iommu. This is required to get PASID managed in system-wide. > > Cc: Kevin Tian > Signed-off-by: Liu Yi L >

RE: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support

2019-10-28 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Saturday, October 26, 2019 1:34 AM > > Hi Kevin, > > > On Fri, 25 Oct 2019 07:19:26 + > "Tian, Kevin" wrote: > > > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com

RE: [PATCH v7 11/11] iommu/vt-d: Add svm/sva invalidate function

2019-10-28 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Saturday, October 26, 2019 3:03 PM > > Hi again, > > On 10/26/19 10:40 AM, Lu Baolu wrote: > > Hi, > > > > On 10/25/19 3:27 PM, Tian, Kevin wrote: > >>> From: Jacob Pan [mailto:jacob.jun.

RE: [PATCH v7 02/11] iommu/vt-d: Enlightened PASID allocation

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > From: Lu Baolu > > Enabling IOMMU in a guest requires communication with the host > driver for certain aspects. Use of PASID ID to enable Shared Virtual > Addressing (SVA) requires managing

RE: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 12:43 PM > > Hi Baolu, > > Thanks for the review. please see my comments inline. > > On Fri, 25 Oct 2019 10:30:48 +0800 > Lu Baolu wrote: > > > Hi Jacob, > > > > On 10/25/19 3:54 AM, Jacob Pan wrote: > >

RE: [PATCH v7 04/11] iommu/vt-d: Replace Intel specific PASID allocator with IOASID

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > Make use of generic IOASID code to manage PASID allocation, > free, and lookup. Replace Intel specific code. > > Signed-off-by: Jacob Pan better push this patch separately. It's a generic

RE: [PATCH v7 07/11] iommu/vt-d: Add nested translation helper function

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8. > With PASID granular translation type set to 0x11b, translation > result from the first level(FL) also subject to a second level(SL)

RE: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > When VT-d driver runs in the guest, PASID allocation must be > performed via virtual command interface. This patch registers a > custom IOASID allocator which takes precedence over the default >

RE: [PATCH v7 06/11] iommu/vt-d: Avoid duplicated code for PASID setup

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > After each setup for PASID entry, related translation caches must be > flushed. > We can combine duplicated code into one function which is less error > prone. > > Signed-off-by: Jacob Pan

RE: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > When supporting guest SVA with emulated IOMMU, the guest PASID > table is shadowed in VMM. Updates to guest vIOMMU PASID table > will result in PASID cache flush which will be passed down to >

RE: [PATCH v7 10/11] iommu/vt-d: Support flushing more translation cache types

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable > IOTLB invalidation may be passed down from outside IOMMU subsystems. from outside of host IOMMU subsystem > This patch

RE: [PATCH v7 11/11] iommu/vt-d: Add svm/sva invalidate function

2019-10-25 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Friday, October 25, 2019 3:55 AM > > When Shared Virtual Address (SVA) is enabled for a guest OS via > vIOMMU, we need to provide invalidation support at IOMMU API and > driver > level. This patch adds Intel VT-d specific function

RE: [RFC v2 0/3] vfio: support Shared Virtual Addressing

2019-10-25 Thread Tian, Kevin
> From: Liu Yi L > Sent: Thursday, October 24, 2019 8:26 PM > > Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel > platforms allow address space sharing between device DMA and > applications. > SVA can reduce programming complexity and enhance security. > This series is

RE: [RFC v2 1/3] vfio: VFIO_IOMMU_CACHE_INVALIDATE

2019-10-25 Thread Tian, Kevin
> From: Liu, Yi L > Sent: Thursday, October 24, 2019 8:26 PM > > From: Liu Yi L > > When the guest "owns" the stage 1 translation structures, the host > IOMMU driver has no knowledge of caching structure updates unless > the guest invalidation requests are trapped and passed down to the >

RE: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support

2019-10-29 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Tuesday, October 29, 2019 12:03 AM > > On Mon, 28 Oct 2019 06:03:36 +0000 > "Tian, Kevin" wrote: > > > > > > + .sva_bind_gpasid= intel_svm_bind_gpasid, > > > > &g

RE: [PATCH v7 02/11] iommu/vt-d: Enlightened PASID allocation

2019-10-29 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Wednesday, October 30, 2019 1:15 AM > > > > > > From: Lu Baolu > > > > > > Enabling IOMMU in a guest requires communication with the host > > > driver for certain aspects. Use of PASID ID to enable Shared Virtual > > > Addressing

RE: [PATCH v7 11/11] iommu/vt-d: Add svm/sva invalidate function

2019-10-29 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Tuesday, October 29, 2019 12:11 AM > > On Mon, 28 Oct 2019 06:06:33 +0000 > "Tian, Kevin" wrote: > > > > >>> +    /* PASID based dev TLBs, only support all PASIDs or sin

RE: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support

2019-10-29 Thread Tian, Kevin
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Wednesday, October 30, 2019 12:12 AM > > On Tue, 29 Oct 2019 07:57:21 +0000 > "Tian, Kevin" wrote: > > > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > > > Sent: Tuesday

RE: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID

2019-10-25 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Friday, October 25, 2019 10:39 PM > > Hi, > > On 10/25/19 2:40 PM, Tian, Kevin wrote: > >>>> ioasid_register_allocator(>pasid_allocator); > >>>> +if (ret) { >

RE: [RFC PATCH 3/4] iommu/vt-d: Map/unmap domain with mmmap/mmunmap

2019-09-24 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Monday, September 23, 2019 8:25 PM > > If a dmar domain has DOMAIN_FLAG_FIRST_LEVEL_TRANS bit set > in its flags, IOMMU will use the first level page table for > translation. Hence, we need to map or unmap addresses in the > first level

RE: [RFC PATCH 2/4] iommu/vt-d: Add first level page table interfaces

2019-09-24 Thread Tian, Kevin
> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Wednesday, September 25, 2019 12:31 PM > > On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote: > > > > intel_mmmap_range(domain, addr, end, phys_addr, prot) > > > > > > Maybe think of a different name..? mmmap seems a bit weird :-) > > > >

RE: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest

2019-09-25 Thread Tian, Kevin
> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Wednesday, September 25, 2019 2:57 PM > > On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote: > > Hi Kevin, > > > > On 9/24

RE: [RFC PATCH 4/4] iommu/vt-d: Identify domains using first level page table

2019-09-25 Thread Tian, Kevin
> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Wednesday, September 25, 2019 2:50 PM > > On Mon, Sep 23, 2019 at 08:24:54PM +0800, Lu Baolu wrote: > > +/* > > + * Check and return whether first level is used by default for > > + * DMA translation. > > + */ > > +static bool

RE: [RFC PATCH 2/4] iommu/vt-d: Add first level page table interfaces

2019-09-25 Thread Tian, Kevin
> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Wednesday, September 25, 2019 2:52 PM > > Hi Peter and Kevin, > > On 9/25/19 1:24 PM, Peter Xu wrote: > > On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote: > >>> From: Peter Xu [mailto:pet.

RE: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest

2019-09-25 Thread Tian, Kevin
> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Wednesday, September 25, 2019 3:45 PM > > On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote: > > > From: Peter Xu [mailto:pet...@redhat.com] > > > Sent: Wednesday, September 25, 2019 2:57 PM > > &

RE: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space

2020-03-05 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early,

RE: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-14 Thread Tian, Kevin
> From: Alex Williamson > Sent: Wednesday, April 15, 2020 8:36 AM > > On Tue, 14 Apr 2020 23:57:33 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Tuesday, April 14, 2020 11:24 PM > > > > > &g

RE: [PATCH v2 1/3] iommu/uapi: Define uapi version and capabilities

2020-04-14 Thread Tian, Kevin
> From: Jacob Pan > Sent: Wednesday, April 15, 2020 6:32 AM > > On Tue, 14 Apr 2020 10:13:04 -0700 > Jacob Pan wrote: > > > > > > In any of the proposed solutions, the > > > > > IOMMU driver is ultimately responsible for validating the user > > > > > data, so do we want vfio performing the

RE: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-14 Thread Tian, Kevin
> From: Alex Williamson > Sent: Tuesday, April 14, 2020 11:24 PM > > On Tue, 14 Apr 2020 03:42:42 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Tuesday, April 14, 2020 11:29 AM > > > > > &g

RE: [PATCH v2 0/7] iommu/vt-d: Add page request draining support

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 1:26 PM > > When a PASID is stopped or terminated, there can be pending PRQs > (requests that haven't received responses) in the software and > remapping hardware. The pending page requests must be drained > so that the pasid could be reused.

RE: [PATCH v2 1/7] iommu/vt-d: Refactor parameters for qi_submit_sync()

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 1:26 PM > > Current qi_submit_sync() supports single invalidation descriptor > per submission and appends wait descriptor after each submission > to poll hardware completion. This patch adjusts the parameters > of this function so that multiple

RE: [PATCH v2 2/7] iommu/vt-d: Multiple descriptors per qi_submit_sync()

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 4:30 PM > > On 2020/4/15 16:18, Tian, Kevin wrote: > >> From: Lu Baolu > >> Sent: Wednesday, April 15, 2020 1:26 PM > >> > >> Extend qi_submit_sync() function to support multiple descriptors. &g

RE: [PATCH v2 5/7] iommu/vt-d: Save prq descriptors in an internal list

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 1:26 PM > > Currently, the page request interrupt thread handles the page > requests in the queue in this way: > > - Clear PPR bit to ensure new interrupt could come in; > - Read and record the head and tail registers; > - Handle all

RE: [PATCH v2 4/7] iommu/vt-d: Refactor prq_event_thread()

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 1:26 PM > > Move the software processing page request descriptors part from > prq_event_thread() into a separated function. No any functional > changes. > > Signed-off-by: Lu Baolu > --- > drivers/iommu/intel-svm.c | 256

RE: [PATCH v2 2/7] iommu/vt-d: Multiple descriptors per qi_submit_sync()

2020-04-15 Thread Tian, Kevin
> From: Lu Baolu > Sent: Wednesday, April 15, 2020 1:26 PM > > Extend qi_submit_sync() function to support multiple descriptors. > > Signed-off-by: Jacob Pan > Signed-off-by: Lu Baolu > --- > drivers/iommu/dmar.c| 39 +++-- >

  1   2   3   4   5   6   >