From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Auger Eric <eric.auger@redhat.com> Cc: iommu@lists.linux-foundation.org, LKML <linux-kernel@vger.kernel.org>, Joerg Roedel <joro@8bytes.org>, David Woodhouse <dwmw2@infradead.org>, Alex Williamson <alex.williamson@redhat.com>, Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com>, Christoph Hellwig <hch@infradead.org>, Lu Baolu <baolu.lu@linux.intel.com>, Andriy Shevchenko <andriy.shevchenko@linux.intel.com>, jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v2 19/19] iommu/vt-d: Add svm/sva invalidate function Date: Mon, 29 Apr 2019 15:41:46 -0700 [thread overview] Message-ID: <20190429154146.20e0c13c@jacob-builder> (raw) In-Reply-To: <26398960-f484-d5dd-eff5-c44810528194@redhat.com> On Fri, 26 Apr 2019 19:23:03 +0200 Auger Eric <eric.auger@redhat.com> wrote: > Hi Jacob, > On 4/24/19 1:31 AM, Jacob Pan wrote: > > 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 to > > implement iommu passdown invalidate API for shared virtual address. > > > > The use case is for supporting caching structure invalidation > > of assigned SVM capable devices. Emulated IOMMU exposes queue > > invalidation capability and passes down all descriptors from the > > guest to the physical IOMMU. > > > > The assumption is that guest to host device ID mapping should be > > resolved prior to calling IOMMU driver. Based on the device handle, > > host IOMMU driver can replace certain fields before submit to the > > invalidation queue. > > > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > > Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com> > > --- > > drivers/iommu/intel-iommu.c | 159 > > ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 > > insertions(+) > > > > diff --git a/drivers/iommu/intel-iommu.c > > b/drivers/iommu/intel-iommu.c index 89989b5..54a3d22 100644 > > --- a/drivers/iommu/intel-iommu.c > > +++ b/drivers/iommu/intel-iommu.c > > @@ -5338,6 +5338,164 @@ static void > > intel_iommu_aux_detach_device(struct iommu_domain *domain, > > aux_domain_remove_dev(to_dmar_domain(domain), dev); } > > > > +/* > > + * 2D array for converting and sanitizing IOMMU generic TLB > > granularity to > > + * VT-d granularity. Invalidation is typically included in the > > unmap operation > > + * as a result of DMA or VFIO unmap. However, for assigned device > > where guest > > + * could own the first level page tables without being shadowed by > > QEMU. In > > + * this case there is no pass down unmap to the host IOMMU as a > > result of unmap > > + * in the guest. Only invalidations are trapped and passed down. > > + * In all cases, only first level TLB invalidation (request with > > PASID) can be > > + * passed down, therefore we do not include IOTLB granularity for > > request > > + * without PASID (second level). > > + * > > + * For an example, to find the VT-d granularity encoding for IOTLB > > + * type and page selective granularity within PASID: > > + * X: indexed by iommu cache type > > + * Y: indexed by enum iommu_inv_granularity > > + * [IOMMU_INV_TYPE_TLB][IOMMU_INV_GRANU_PAGE_PASID] > > + * > > + * Granu_map array indicates validity of the table. 1: valid, 0: > > invalid > > + * > > + */ > > +const static int > > inv_type_granu_map[NR_IOMMU_CACHE_TYPE][NR_IOMMU_CACHE_INVAL_GRANU] > > = { > The size is frozen for a given uapi version so I guess you can > hardcode the limits for a given version. I guess I could, I just felt more readable this way. > > + /* PASID based IOTLB, support PASID selective and page > > selective */ > > + {0, 1, 1}, > > + /* PASID based dev TLBs, only support all PASIDs or single > > PASID */ > > + {1, 1, 0}, > > + /* PASID cache */ > > + {1, 1, 0} > > +}; > > + > > +const static u64 > > inv_type_granu_table[NR_IOMMU_CACHE_TYPE][NR_IOMMU_CACHE_INVAL_GRANU] > > = { > > + /* PASID based IOTLB */ > > + {0, QI_GRAN_NONG_PASID, QI_GRAN_PSI_PASID}, > > + /* PASID based dev TLBs */ > > + {QI_DEV_IOTLB_GRAN_ALL, QI_DEV_IOTLB_GRAN_PASID_SEL, 0}, > > + /* PASID cache */ > > + {QI_PC_ALL_PASIDS, QI_PC_PASID_SEL, 0}, > > +}; > Can't you use a single matrix instead, ie. inv_type_granu_table > The reason i have an additional inv_type_granu_map[] matrix is that some of fields can be 0 but still valid. A single matrix would not be able to tell the difference between a valid 0 or invalid field. > > + > > +static inline int to_vtd_granularity(int type, int granu, u64 > > *vtd_granu) +{ > > + if (type >= NR_IOMMU_CACHE_TYPE || granu >= > > NR_IOMMU_CACHE_INVAL_GRANU || > > + !inv_type_granu_map[type][granu]) > > + return -EINVAL; > > + > > + *vtd_granu = inv_type_granu_table[type][granu]; > > + > > + return 0; > > +} > > + > > +static inline u64 to_vtd_size(u64 granu_size, u64 nr_granules) > > +{ > > + u64 nr_pages; > direct initialization? will do, thanks > > + /* VT-d size is encoded as 2^size of 4K pages, 0 for 4k, 9 > > for 2MB, etc. > > + * IOMMU cache invalidate API passes granu_size in bytes, > > and number of > > + * granu size in contiguous memory. > > + */ > > + > > + nr_pages = (granu_size * nr_granules) >> VTD_PAGE_SHIFT; > > + return order_base_2(nr_pages); > > +} > > + > > +static int intel_iommu_sva_invalidate(struct iommu_domain *domain, > > + struct device *dev, struct > > iommu_cache_invalidate_info *inv_info) +{ > > + struct dmar_domain *dmar_domain = to_dmar_domain(domain); > > + struct device_domain_info *info; > > + struct intel_iommu *iommu; > > + unsigned long flags; > > + int cache_type; > > + u8 bus, devfn; > > + u16 did, sid; > > + int ret = 0; > > + u64 granu; > > + u64 size; > > + > > + if (!inv_info || !dmar_domain || > > + inv_info->version != > > IOMMU_CACHE_INVALIDATE_INFO_VERSION_1) > > + return -EINVAL; > > + > > + if (!dev || !dev_is_pci(dev)) > > + return -ENODEV; > > + > > + iommu = device_to_iommu(dev, &bus, &devfn); > > + if (!iommu) > > + return -ENODEV; > > + > > + spin_lock(&iommu->lock); > > + spin_lock_irqsave(&device_domain_lock, flags); > mix of _irqsave and non _irqsave looks suspicious to me. It should be in reverse order. Any other concerns? > > + info = iommu_support_dev_iotlb(dmar_domain, iommu, bus, > > devfn); > > + if (!info) { > > + ret = -EINVAL; > > + goto out_unlock; > > + } > > + did = dmar_domain->iommu_did[iommu->seq_id]; > > + sid = PCI_DEVID(bus, devfn); > > + size = to_vtd_size(inv_info->addr_info.granule_size, > > inv_info->addr_info.nb_granules); + > > + for_each_set_bit(cache_type, (unsigned long > > *)&inv_info->cache, NR_IOMMU_CACHE_TYPE) { + > > + ret = to_vtd_granularity(cache_type, > > inv_info->granularity, &granu); > > + if (ret) { > > + pr_err("Invalid range type %d, granu > > %d\n", cache_type, > s/Invalid range type %d, granu %d/Invalid cache type/granu combination > (%d/%d) sounds good, indeed it is the combination that is invalid. > > + inv_info->granularity); > > + break; > > + } > > + > > + switch (BIT(cache_type)) { > > + case IOMMU_CACHE_INV_TYPE_IOTLB: > > + if (size && (inv_info->addr_info.addr & > > ((BIT(VTD_PAGE_SHIFT + size)) - 1))) { > > + pr_err("Address out of range, > > 0x%llx, size order %llu\n", > > + inv_info->addr_info.addr, > > size); > > + ret = -ERANGE; > > + goto out_unlock; > > + } > > + > > + qi_flush_piotlb(iommu, did, > > mm_to_dma_pfn(inv_info->addr_info.addr), > > + inv_info->addr_info.pasid, > > + size, granu); > > + > > + /* > > + * Always flush device IOTLB if ATS is > > enabled since guest > > + * vIOMMU exposes CM = 1, no device IOTLB > > flush will be passed > > + * down. REVISIT: cannot assume Linux guest > > + */ > > + if (info->ats_enabled) { > > + qi_flush_dev_piotlb(iommu, sid, > > info->pfsid, > > + > > inv_info->addr_info.pasid, info->ats_qdep, > > + > > inv_info->addr_info.addr, size, > > + granu); > > + } > > + break; > > + case IOMMU_CACHE_INV_TYPE_DEV_IOTLB: > > + if (info->ats_enabled) { > > + qi_flush_dev_piotlb(iommu, sid, > > info->pfsid, > > + > > inv_info->addr_info.pasid, info->ats_qdep, > > + > > inv_info->addr_info.addr, size, > > + granu); > > + } else > > + pr_warn("Passdown device IOTLB > > flush w/o ATS!\n"); + > > + break; > > + case IOMMU_CACHE_INV_TYPE_PASID: > > + qi_flush_pasid_cache(iommu, did, granu, > > inv_info->pasid); + > > + break; > > + default: > > + dev_err(dev, "Unsupported IOMMU > > invalidation type %d\n", > > + cache_type); > > + ret = -EINVAL; > > + } > > + } > > +out_unlock: > > + spin_unlock(&iommu->lock); > > + spin_unlock_irqrestore(&device_domain_lock, flags); > I would expect the opposite order yes, i reversed in the lock order such that irq is disabled. > > + > > + return ret; > > +} > > + > > static int intel_iommu_map(struct iommu_domain *domain, > > unsigned long iova, phys_addr_t hpa, > > size_t size, int iommu_prot) > > @@ -5769,6 +5927,7 @@ const struct iommu_ops intel_iommu_ops = { > > .dev_disable_feat = intel_iommu_dev_disable_feat, > > .pgsize_bitmap = INTEL_IOMMU_PGSIZES, > > #ifdef CONFIG_INTEL_IOMMU_SVM > > + .cache_invalidate = intel_iommu_sva_invalidate, > > .sva_bind_gpasid = intel_svm_bind_gpasid, > > .sva_unbind_gpasid = intel_svm_unbind_gpasid, > > #endif > > > Thanks > > Eric Thank you so much for your review. I will roll up the next version soon, hopefully this week. Jacob
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Auger Eric <eric.auger@redhat.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com>, Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, iommu@lists.linux-foundation.org, LKML <linux-kernel@vger.kernel.org>, Alex Williamson <alex.williamson@redhat.com>, Andriy Shevchenko <andriy.shevchenko@linux.intel.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v2 19/19] iommu/vt-d: Add svm/sva invalidate function Date: Mon, 29 Apr 2019 15:41:46 -0700 [thread overview] Message-ID: <20190429154146.20e0c13c@jacob-builder> (raw) Message-ID: <20190429224146.jhG1xvqE6tGoh2EylhnOafErCSQ8DswZ28PldZUt1tg@z> (raw) In-Reply-To: <26398960-f484-d5dd-eff5-c44810528194@redhat.com> On Fri, 26 Apr 2019 19:23:03 +0200 Auger Eric <eric.auger@redhat.com> wrote: > Hi Jacob, > On 4/24/19 1:31 AM, Jacob Pan wrote: > > 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 to > > implement iommu passdown invalidate API for shared virtual address. > > > > The use case is for supporting caching structure invalidation > > of assigned SVM capable devices. Emulated IOMMU exposes queue > > invalidation capability and passes down all descriptors from the > > guest to the physical IOMMU. > > > > The assumption is that guest to host device ID mapping should be > > resolved prior to calling IOMMU driver. Based on the device handle, > > host IOMMU driver can replace certain fields before submit to the > > invalidation queue. > > > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > > Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com> > > --- > > drivers/iommu/intel-iommu.c | 159 > > ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 > > insertions(+) > > > > diff --git a/drivers/iommu/intel-iommu.c > > b/drivers/iommu/intel-iommu.c index 89989b5..54a3d22 100644 > > --- a/drivers/iommu/intel-iommu.c > > +++ b/drivers/iommu/intel-iommu.c > > @@ -5338,6 +5338,164 @@ static void > > intel_iommu_aux_detach_device(struct iommu_domain *domain, > > aux_domain_remove_dev(to_dmar_domain(domain), dev); } > > > > +/* > > + * 2D array for converting and sanitizing IOMMU generic TLB > > granularity to > > + * VT-d granularity. Invalidation is typically included in the > > unmap operation > > + * as a result of DMA or VFIO unmap. However, for assigned device > > where guest > > + * could own the first level page tables without being shadowed by > > QEMU. In > > + * this case there is no pass down unmap to the host IOMMU as a > > result of unmap > > + * in the guest. Only invalidations are trapped and passed down. > > + * In all cases, only first level TLB invalidation (request with > > PASID) can be > > + * passed down, therefore we do not include IOTLB granularity for > > request > > + * without PASID (second level). > > + * > > + * For an example, to find the VT-d granularity encoding for IOTLB > > + * type and page selective granularity within PASID: > > + * X: indexed by iommu cache type > > + * Y: indexed by enum iommu_inv_granularity > > + * [IOMMU_INV_TYPE_TLB][IOMMU_INV_GRANU_PAGE_PASID] > > + * > > + * Granu_map array indicates validity of the table. 1: valid, 0: > > invalid > > + * > > + */ > > +const static int > > inv_type_granu_map[NR_IOMMU_CACHE_TYPE][NR_IOMMU_CACHE_INVAL_GRANU] > > = { > The size is frozen for a given uapi version so I guess you can > hardcode the limits for a given version. I guess I could, I just felt more readable this way. > > + /* PASID based IOTLB, support PASID selective and page > > selective */ > > + {0, 1, 1}, > > + /* PASID based dev TLBs, only support all PASIDs or single > > PASID */ > > + {1, 1, 0}, > > + /* PASID cache */ > > + {1, 1, 0} > > +}; > > + > > +const static u64 > > inv_type_granu_table[NR_IOMMU_CACHE_TYPE][NR_IOMMU_CACHE_INVAL_GRANU] > > = { > > + /* PASID based IOTLB */ > > + {0, QI_GRAN_NONG_PASID, QI_GRAN_PSI_PASID}, > > + /* PASID based dev TLBs */ > > + {QI_DEV_IOTLB_GRAN_ALL, QI_DEV_IOTLB_GRAN_PASID_SEL, 0}, > > + /* PASID cache */ > > + {QI_PC_ALL_PASIDS, QI_PC_PASID_SEL, 0}, > > +}; > Can't you use a single matrix instead, ie. inv_type_granu_table > The reason i have an additional inv_type_granu_map[] matrix is that some of fields can be 0 but still valid. A single matrix would not be able to tell the difference between a valid 0 or invalid field. > > + > > +static inline int to_vtd_granularity(int type, int granu, u64 > > *vtd_granu) +{ > > + if (type >= NR_IOMMU_CACHE_TYPE || granu >= > > NR_IOMMU_CACHE_INVAL_GRANU || > > + !inv_type_granu_map[type][granu]) > > + return -EINVAL; > > + > > + *vtd_granu = inv_type_granu_table[type][granu]; > > + > > + return 0; > > +} > > + > > +static inline u64 to_vtd_size(u64 granu_size, u64 nr_granules) > > +{ > > + u64 nr_pages; > direct initialization? will do, thanks > > + /* VT-d size is encoded as 2^size of 4K pages, 0 for 4k, 9 > > for 2MB, etc. > > + * IOMMU cache invalidate API passes granu_size in bytes, > > and number of > > + * granu size in contiguous memory. > > + */ > > + > > + nr_pages = (granu_size * nr_granules) >> VTD_PAGE_SHIFT; > > + return order_base_2(nr_pages); > > +} > > + > > +static int intel_iommu_sva_invalidate(struct iommu_domain *domain, > > + struct device *dev, struct > > iommu_cache_invalidate_info *inv_info) +{ > > + struct dmar_domain *dmar_domain = to_dmar_domain(domain); > > + struct device_domain_info *info; > > + struct intel_iommu *iommu; > > + unsigned long flags; > > + int cache_type; > > + u8 bus, devfn; > > + u16 did, sid; > > + int ret = 0; > > + u64 granu; > > + u64 size; > > + > > + if (!inv_info || !dmar_domain || > > + inv_info->version != > > IOMMU_CACHE_INVALIDATE_INFO_VERSION_1) > > + return -EINVAL; > > + > > + if (!dev || !dev_is_pci(dev)) > > + return -ENODEV; > > + > > + iommu = device_to_iommu(dev, &bus, &devfn); > > + if (!iommu) > > + return -ENODEV; > > + > > + spin_lock(&iommu->lock); > > + spin_lock_irqsave(&device_domain_lock, flags); > mix of _irqsave and non _irqsave looks suspicious to me. It should be in reverse order. Any other concerns? > > + info = iommu_support_dev_iotlb(dmar_domain, iommu, bus, > > devfn); > > + if (!info) { > > + ret = -EINVAL; > > + goto out_unlock; > > + } > > + did = dmar_domain->iommu_did[iommu->seq_id]; > > + sid = PCI_DEVID(bus, devfn); > > + size = to_vtd_size(inv_info->addr_info.granule_size, > > inv_info->addr_info.nb_granules); + > > + for_each_set_bit(cache_type, (unsigned long > > *)&inv_info->cache, NR_IOMMU_CACHE_TYPE) { + > > + ret = to_vtd_granularity(cache_type, > > inv_info->granularity, &granu); > > + if (ret) { > > + pr_err("Invalid range type %d, granu > > %d\n", cache_type, > s/Invalid range type %d, granu %d/Invalid cache type/granu combination > (%d/%d) sounds good, indeed it is the combination that is invalid. > > + inv_info->granularity); > > + break; > > + } > > + > > + switch (BIT(cache_type)) { > > + case IOMMU_CACHE_INV_TYPE_IOTLB: > > + if (size && (inv_info->addr_info.addr & > > ((BIT(VTD_PAGE_SHIFT + size)) - 1))) { > > + pr_err("Address out of range, > > 0x%llx, size order %llu\n", > > + inv_info->addr_info.addr, > > size); > > + ret = -ERANGE; > > + goto out_unlock; > > + } > > + > > + qi_flush_piotlb(iommu, did, > > mm_to_dma_pfn(inv_info->addr_info.addr), > > + inv_info->addr_info.pasid, > > + size, granu); > > + > > + /* > > + * Always flush device IOTLB if ATS is > > enabled since guest > > + * vIOMMU exposes CM = 1, no device IOTLB > > flush will be passed > > + * down. REVISIT: cannot assume Linux guest > > + */ > > + if (info->ats_enabled) { > > + qi_flush_dev_piotlb(iommu, sid, > > info->pfsid, > > + > > inv_info->addr_info.pasid, info->ats_qdep, > > + > > inv_info->addr_info.addr, size, > > + granu); > > + } > > + break; > > + case IOMMU_CACHE_INV_TYPE_DEV_IOTLB: > > + if (info->ats_enabled) { > > + qi_flush_dev_piotlb(iommu, sid, > > info->pfsid, > > + > > inv_info->addr_info.pasid, info->ats_qdep, > > + > > inv_info->addr_info.addr, size, > > + granu); > > + } else > > + pr_warn("Passdown device IOTLB > > flush w/o ATS!\n"); + > > + break; > > + case IOMMU_CACHE_INV_TYPE_PASID: > > + qi_flush_pasid_cache(iommu, did, granu, > > inv_info->pasid); + > > + break; > > + default: > > + dev_err(dev, "Unsupported IOMMU > > invalidation type %d\n", > > + cache_type); > > + ret = -EINVAL; > > + } > > + } > > +out_unlock: > > + spin_unlock(&iommu->lock); > > + spin_unlock_irqrestore(&device_domain_lock, flags); > I would expect the opposite order yes, i reversed in the lock order such that irq is disabled. > > + > > + return ret; > > +} > > + > > static int intel_iommu_map(struct iommu_domain *domain, > > unsigned long iova, phys_addr_t hpa, > > size_t size, int iommu_prot) > > @@ -5769,6 +5927,7 @@ const struct iommu_ops intel_iommu_ops = { > > .dev_disable_feat = intel_iommu_dev_disable_feat, > > .pgsize_bitmap = INTEL_IOMMU_PGSIZES, > > #ifdef CONFIG_INTEL_IOMMU_SVM > > + .cache_invalidate = intel_iommu_sva_invalidate, > > .sva_bind_gpasid = intel_svm_bind_gpasid, > > .sva_unbind_gpasid = intel_svm_unbind_gpasid, > > #endif > > > Thanks > > Eric Thank you so much for your review. I will roll up the next version soon, hopefully this week. Jacob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-04-29 22:39 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-23 23:31 [PATCH v2 00/19] Shared virtual address IOMMU and VT-d support Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 01/19] driver core: add per device iommu param Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 02/19] iommu: introduce device fault data Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-25 12:46 ` Jean-Philippe Brucker 2019-04-25 12:46 ` Jean-Philippe Brucker 2019-04-25 13:21 ` Auger Eric 2019-04-25 13:21 ` Auger Eric 2019-04-25 14:33 ` Jean-Philippe Brucker 2019-04-25 14:33 ` Jean-Philippe Brucker 2019-04-25 18:07 ` Jacob Pan 2019-04-25 18:07 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 03/19] iommu: introduce device fault report API Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 04/19] iommu: Introduce attach/detach_pasid_table API Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 05/19] iommu: Introduce cache_invalidate API Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 06/19] drivers core: Add I/O ASID allocator Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-24 6:19 ` Christoph Hellwig 2019-04-24 6:19 ` Christoph Hellwig 2019-04-25 18:19 ` Jacob Pan 2019-04-25 18:19 ` Jacob Pan 2019-04-25 18:19 ` Jacob Pan 2019-04-26 11:47 ` Jean-Philippe Brucker 2019-04-26 11:47 ` Jean-Philippe Brucker 2019-04-26 12:21 ` Christoph Hellwig 2019-04-26 12:21 ` Christoph Hellwig 2019-04-26 16:58 ` Jacob Pan 2019-04-26 16:58 ` Jacob Pan 2019-04-25 10:17 ` Auger Eric 2019-04-25 10:17 ` Auger Eric 2019-04-25 10:41 ` Jean-Philippe Brucker 2019-04-25 10:41 ` Jean-Philippe Brucker 2019-04-30 20:24 ` Jacob Pan 2019-04-30 20:24 ` Jacob Pan 2019-05-01 17:40 ` Jean-Philippe Brucker 2019-05-01 17:40 ` Jean-Philippe Brucker 2019-04-23 23:31 ` [PATCH v2 07/19] ioasid: Convert ioasid_idr to XArray Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 08/19] ioasid: Add custom IOASID allocator Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-25 10:03 ` Auger Eric 2019-04-25 10:03 ` Auger Eric 2019-04-25 21:29 ` Jacob Pan 2019-04-25 21:29 ` Jacob Pan 2019-04-26 9:06 ` Auger Eric 2019-04-26 9:06 ` Auger Eric 2019-04-26 15:19 ` Jacob Pan 2019-04-26 15:19 ` Jacob Pan 2019-05-06 17:59 ` Jacob Pan 2019-05-06 17:59 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 09/19] iommu/vt-d: Enlightened PASID allocation Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-25 7:12 ` Liu, Yi L 2019-04-25 7:12 ` Liu, Yi L 2019-04-25 7:40 ` Auger Eric 2019-04-25 7:40 ` Auger Eric 2019-04-25 23:01 ` Jacob Pan 2019-04-25 23:01 ` Jacob Pan 2019-04-25 23:01 ` Jacob Pan 2019-04-25 23:40 ` Jacob Pan 2019-04-25 23:40 ` Jacob Pan 2019-04-26 7:24 ` Auger Eric 2019-04-26 7:24 ` Auger Eric 2019-04-26 15:05 ` Jacob Pan 2019-04-26 15:05 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 10/19] iommu/vt-d: Add custom allocator for IOASID Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-26 20:11 ` Jacob Pan 2019-04-26 20:11 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 11/19] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-25 10:04 ` Auger Eric 2019-04-25 10:04 ` Auger Eric [not found] ` <e542fd95-acbe-05e9-e441-27dff752c21a-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2019-04-26 21:01 ` Jacob Pan 2019-04-26 21:01 ` Jacob Pan 2019-04-27 8:38 ` Auger Eric 2019-04-27 8:38 ` Auger Eric 2019-04-29 10:00 ` Jean-Philippe Brucker 2019-04-29 10:00 ` Jean-Philippe Brucker 2019-04-23 23:31 ` [PATCH v2 12/19] iommu/vt-d: Move domain helper to header Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-24 17:27 ` Auger Eric 2019-04-23 23:31 ` [PATCH v2 13/19] iommu/vt-d: Add nested translation support Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 15:42 ` Auger Eric 2019-04-26 15:42 ` Auger Eric 2019-04-26 21:57 ` Jacob Pan 2019-04-26 21:57 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 14/19] iommu: Add guest PASID bind function Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 15:53 ` Auger Eric 2019-04-26 15:53 ` Auger Eric 2019-04-26 22:11 ` Jacob Pan 2019-04-26 22:11 ` Jacob Pan 2019-04-27 8:37 ` Auger Eric 2019-04-27 8:37 ` Auger Eric 2019-04-23 23:31 ` [PATCH v2 15/19] iommu/vt-d: Add bind guest PASID support Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 16:15 ` Auger Eric 2019-04-26 16:15 ` Auger Eric 2019-04-29 15:25 ` Jacob Pan 2019-04-29 15:25 ` Jacob Pan 2019-04-30 7:05 ` Auger Eric 2019-04-30 7:05 ` Auger Eric 2019-04-30 17:49 ` Jacob Pan 2019-04-30 17:49 ` Jacob Pan 2019-04-23 23:31 ` [PATCH v2 16/19] iommu/vtd: Clean up for SVM device list Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 16:19 ` Auger Eric 2019-04-26 16:19 ` Auger Eric 2019-04-23 23:31 ` [PATCH v2 17/19] iommu: Add max num of cache and granu types Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 16:22 ` Auger Eric 2019-04-26 16:22 ` Auger Eric 2019-04-29 16:17 ` Jacob Pan 2019-04-29 16:17 ` Jacob Pan 2019-04-30 5:15 ` Auger Eric 2019-04-30 5:15 ` Auger Eric 2019-04-23 23:31 ` [PATCH v2 18/19] iommu/vt-d: Support flushing more translation cache types Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-27 9:04 ` Auger Eric 2019-04-27 9:04 ` Auger Eric 2019-04-29 21:29 ` Jacob Pan 2019-04-29 21:29 ` Jacob Pan 2019-04-30 4:41 ` Auger Eric 2019-04-30 4:41 ` Auger Eric 2019-04-30 4:41 ` Auger Eric 2019-04-30 17:15 ` Jacob Pan 2019-04-30 17:15 ` Jacob Pan 2019-04-30 17:41 ` Auger Eric 2019-04-30 17:41 ` Auger Eric 2019-04-23 23:31 ` [PATCH v2 19/19] iommu/vt-d: Add svm/sva invalidate function Jacob Pan 2019-04-23 23:31 ` Jacob Pan 2019-04-26 17:23 ` Auger Eric 2019-04-26 17:23 ` Auger Eric 2019-04-29 22:41 ` Jacob Pan [this message] 2019-04-29 22:41 ` Jacob Pan 2019-04-30 6:57 ` Auger Eric 2019-04-30 6:57 ` Auger Eric 2019-04-30 17:22 ` Jacob Pan 2019-04-30 17:22 ` Jacob Pan 2019-04-30 17:36 ` Auger Eric 2019-04-30 17:36 ` Auger Eric
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190429154146.20e0c13c@jacob-builder \ --to=jacob.jun.pan@linux.intel.com \ --cc=alex.williamson@redhat.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=hch@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jean-philippe.brucker@arm.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=yi.l.liu@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.