RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 11, 2016 11:54 PM > > On Wed, 11 May 2016 06:29:06 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, May 12, 2016 10:21 AM > > On Thu, 12 May 2016 01:19:44 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] &

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Tian, Kevin > Sent: Friday, May 13, 2016 10:33 AM > > > means. The MSI-X vector table of a device is always considered > > untrusted which is why we require user opt-ins to subvert that > > protection. Thanks, > > > > I only partially agree with

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, May 13, 2016 1:33 PM > > > > > > As argued previously in this thread, there's nothing special about a > > > DMA write to memory versus a DMA write to a special address that > > > triggers an MSI vector. If the device is

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, May 13, 2016 1:48 AM > > On Thu, 12 May 2016 04:53:19 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, May 05, 2016 11:05 PM > > On Thu, 5 May 2016 12:15:46 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:43 PM > > This patch enables mmapping MSI-X tables if hardware supports > interrupt remapping which can ensure that a given pci device > can only shoot the MSIs assigned for it. > > With MSI-X table mmapped, we also need to expose the >

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > Sent: Tuesday, May 03, 2016 2:08 PM > > On 2016/5/3 13:34, Tian, Kevin wrote: > > >> From: Yongji Xie > >> Sent: Wednesday, April 27, 2016 8:43 PM > >> > >> This patch enables mmappi

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Yongji Xie > Sent: Tuesday, May 03, 2016 3:34 PM > > On 2016/5/3 14:22, Tian, Kevin wrote: > > >> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > >> Sent: Tuesday, May 03, 2016 2:08 PM > >> > >> On 2016/5/3 13:34, Tian, Ke

RE: [RFC PATCH 30/30] vfio: Allow to bind foreign task

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Tuesday, February 28, 2017 11:23 PM > > Hi Kevin, > > On Tue, Feb 28, 2017 at 06:43:31AM +, Tian, Kevin wrote: > > > From: Alex Williamson > > > Sent: Tuesday, February 28, 2017

RE: [RFC PATCH 22/30] iommu: Bind/unbind tasks to/from devices

> From: Jean-Philippe Brucker > Sent: Tuesday, February 28, 2017 3:55 AM > [...] > > API naming > == > > I realize that "SVM" as a name isn't great because the svm namespace is > already taken by AMD-V (Secure Virtual Machine) in arch/x86. Also, the > name itself doesn't say much. >

RE: [RFC Design Doc v3] Enable Shared Virtual Memory feature in pass-through scenarios

> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Wednesday, March 01, 2017 6:07 AM > > On Wed, Nov 30, 2016 at 08:49:24AM +, Liu, Yi L wrote: > > What's changed from v2: > > a) Detailed feature description > > b) refine description in "Address translation in virtual SVM"

RE: [RFC 1/3] virtio-iommu: firmware description of the virtual topology

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike oth

RE: [RFC 3/3] virtio-iommu: future work

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Here I propose a few ideas for extensions and optimizations. This is all > very exploratory, feel free to correct mistakes and suggest more things. [...] > > II. Page table sharing > == > > 1.

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

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, April 19, 2017 2:46 AM > > On 18/04/17 11:26, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >

RE: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

> From: Jason Wang > Sent: Wednesday, April 12, 2017 5:07 PM > > On 2017年04月08日 03:17, Jean-Philippe Brucker wrote: > > This is the initial proposal for a paravirtualized IOMMU device using > > virtio transport. It contains a description of the device, a Linux driver, > > and a toy implementation

RE: [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, April 12, 2017 9:22 PM > [...] > By my limited understanding of VT-d details: The stolen memory is never > directly accessed by i915 driver (because CPU access doesn't work even > in DOM0). It is only used through

RE: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > This is the initial proposal for a paravirtualized IOMMU device using > virtio transport. It contains a description of the device, a Linux driver, > and a toy implementation in kvmtool. With this prototype, you can >

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

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious

RE: Support SVM without PASID

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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 v4 05/22] iommu: introduce iommu invalidate API function

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, April 28, 2018 2:08 AM > > [...] > >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should > >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it > >> different from

RE: [PATCH v2 0/9] iommu/vt-d: Improve PASID id and table management

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Wednesday, May 16, 2018 4:01 PM > > Hi Joerg, > > Thank you for looking at my patches. > > On 05/15/2018 10:11 PM, Joerg Roedel wrote: > > On Fri, May 04, 2018 at 09:41:15AM +0800, Lu Baolu wrote: > >> PATCH 4~9 implement per domain

RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, June 7, 2018 11:02 PM > > On Wed, 6 Jun 2018 05:29:58 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Wednesday, June 6, 2018 3:07 AM > > >

RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 4:09 AM > > On Fri, 20 Apr 2018 16:42:51 -0700 > Jacob Pan wrote: > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > Jean-Philippe Brucker wrote: > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex

RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesda

RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges

> From: Alex Williamson > Sent: Wednesday, June 6, 2018 3:07 AM > > device_is_rmrr_locked() allows graphics and USB devices to participate > in the IOMMU API despite, and ignoring their RMRR association, however > intel_iommu_get_resv_regions() still includes the RMRRs as unavailable > IOVA space

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

> 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

> 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

> 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

> 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

> 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

> 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: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Tian, Kevin > Sent: Thursday, July 26, 2018 11:04 AM [...] > > > > The IOMMU operations we care about don't take a device handle, I think, > > just a domain. And VFIO itself only deals with domains when doing > > map/unmap. Maybe we could add this oper

RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, July 26, 2018 3:20 AM > > On 25/07/18 07:19, Tian, Kevin wrote: > >> From: Tian, Kevin > >> Sent: Wednesday, July 25, 2018 10:16 AM > >> > > [...] > >>

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

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

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 > > &

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

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 > > >

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

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.

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

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 &g

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

> From: Kenneth Lee [mailto:liguo...@hisilicon.com] > Sent: Thursday, August 9, 2018 4:04 PM > > But we have another requirement which is to combine some device > together to > share the same address space. This is a little like these kinds of solution: > >

RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Jean-Philippe Brucker > Sent: Tuesday, July 24, 2018 7:31 PM > > Hi Baolu, > > On 24/07/18 03:22, Lu Baolu wrote: > > Hi, > > > > On 07/23/2018 12:44 PM, Liu, Yi L wrote: > >>> From: Lu Baolu [mailto:baolu...@linux.intel.com] > >>> Sent: Sunday, July 22, 2018 2:09 PM > >>> > >>> With the

RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Tian, Kevin > Sent: Wednesday, July 25, 2018 10:16 AM > [...] > > > > There is another way: as we're planning to add a generic pasid_alloc() > > function to the IOMMU API, the mdev module itself could allocate a > > default PASID for each mdev by ca

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

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 12:09 PM > [...] > > In order to distinguish the IOMMU-capable mediated devices from those > which still need to rely on parent devices, this patch set adds a > domain type attribute to each mdev. > > enum

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

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Tuesday, September 4, 2018 5:53 PM > > On 04/09/2018 09:41, Auger Eric wrote: > > I think the confusion comes from the different terminology used in VTD > > and ARM SMMU spec. > > > > Your PASID table ~ ARM SMMU Context

RE: [PATCH v2 04/12] iommu/vt-d: Add 256-bit invalidation descriptor support

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > Intel vt-d spec rev3.0 requires software to use 256-bit > descriptors in invalidation queue. As the spec reads in > section 6.5.2: > > Remapping hardware supporting Scalable Mode Translations >

RE: [PATCH v2 02/12] iommu/vt-d: Manage scalalble mode PASID tables

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, September 6, 2018 10:46 AM > [...] > >> @@ -143,8 +142,9 @@ int intel_pasid_alloc_table(struct device *dev) > >>return -ENOMEM; > >>INIT_LIST_HEAD(_table->dev); > >> > >> - size = sizeof(struct pasid_entry); >

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

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > This adds the interfaces to setup or tear down the structures > for second level page table translations. This includes types > of second level only translation and pass through. > > Cc: Ashok Raj >

RE: [PATCH v2 08/12] iommu/vt-d: Pass pasid table to context mapping

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > So that the pasid related info, such as the pasid table and the > maximum of pasid could be used during setting up scalable mode > context. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc:

RE: [PATCH v2 03/12] iommu/vt-d: Move page table helpers into header

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > So that they could also be used in other source files. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Signed-off-by: Lu Baolu > Reviewed-by: Ashok Raj Reviewed-by: Kevin

RE: [PATCH v2 01/12] iommu/vt-d: Enumerate the scalable mode capability

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > The Intel vt-d spec rev3.0 introduces a new translation > mode called scalable mode, which enables PASID-granular > translations for first level, second level, nested and > pass-through modes. At the

RE: [PATCH v2 02/12] iommu/vt-d: Manage scalalble mode PASID tables

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, August 30, 2018 9:35 AM > > In scalable mode, pasid structure is a two level table with > a pasid directory table and a pasid table. Any pasid entry > can be identified by a pasid value in below way. > >1 >9

RE: Question on IOMMU indentity mapping for intel-iommu

> 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

> 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 1/4] iommu: Add virtio-iommu driver

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

  1   2   3   4   5   6   7   8   >