Hi Jason,
On Tue, 31 May 2022 16:05:50 -0300, Jason Gunthorpe wrote:
> On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote:
>
> > The reason why I store PASID at IOMMU domain is for IOTLB flush within
> > the domain. Device driver is not aware of domain level IOTLB
Hi Baolu,
On Tue, 31 May 2022 20:45:28 +0800, Baolu Lu
wrote:
> On 2022/5/31 18:12, Tian, Kevin wrote:
> +++ b/include/linux/iommu.h
> @@ -105,6 +105,8 @@ struct iommu_domain {
> enum iommu_page_response_code (*iopf_handler)(struct
> >> iommu_fault *fault,
>
Hi Jason,
On Tue, 24 May 2022 15:02:41 -0300, Jason Gunthorpe wrote:
> On Tue, May 24, 2022 at 09:12:35AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Tue, 24 May 2022 10:51:35 -0300, Jason Gunthorpe
> > wrote:
> > > On Wed, May 18, 2022
Hi Jason,
On Tue, 24 May 2022 10:51:35 -0300, Jason Gunthorpe wrote:
> On Wed, May 18, 2022 at 11:21:17AM -0700, Jacob Pan wrote:
> > On VT-d platforms with scalable mode enabled, devices issue DMA requests
> > with PASID need to attach PASIDs to given IOMMU domains. The attac
Hi Jason,
On Tue, 24 May 2022 10:50:34 -0300, Jason Gunthorpe wrote:
> On Wed, May 18, 2022 at 11:21:15AM -0700, Jacob Pan wrote:
> > DMA requests tagged with PASID can target individual IOMMU domains.
> > Introduce a domain-wide PASID for DMA API, it will be used on the s
Hi Kevin,
On Mon, 23 May 2022 09:14:04 +, "Tian, Kevin"
wrote:
> > From: Tian, Kevin
> > Sent: Monday, May 23, 2022 3:55 PM
> >
> > > From: Jacob Pan
> > > +ioasid_t iommu_get_pasid_from_domain(struct device *dev, struct
> > > iom
Hi Kevin,
On Mon, 23 May 2022 08:25:33 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Thursday, May 19, 2022 2:21 AM
> >
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not P
Hi Christoph,
On Wed, 18 May 2022 23:48:44 -0700, Christoph Hellwig
wrote:
> On Wed, May 18, 2022 at 11:21:16AM -0700, Jacob Pan wrote:
> > +ioasid_t iommu_get_pasid_from_domain(struct device *dev, struct
> > iommu_domain *domain)
>
> Overly long line here.
will
Hi Jason,
On Wed, 18 May 2022 15:52:05 -0300, Jason Gunthorpe wrote:
> On Wed, May 18, 2022 at 11:42:04AM -0700, Jacob Pan wrote:
>
> > > Yes.. It seems inefficient to iterate over that xarray multiple times
> > > on the flush hot path, but maybe there is little choi
Hi Baolu,
On Thu, 19 May 2022 14:41:06 +0800, Baolu Lu
wrote:
> > IOMMU group maintains a PASID array which stores the associated IOMMU
> > domains. This patch introduces a helper function to do domain to PASID
> > look up. It will be used by TLB flush and device-PASID attach
> > verification.
Hi Jason,
On Wed, 11 May 2022 15:29:08 -0300, Jason Gunthorpe wrote:
> On Wed, May 11, 2022 at 10:25:21AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 11 May 2022 14:00:25 -0300, Jason Gunthorpe
> > wrote:
> > > On Wed, May 11, 2022
Supervisor PASID for SVA/SVM is no longer supported, delete the unused
flag.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 2 +-
include/linux/intel-svm.h | 13 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu
IOMMU group maintains a PASID array which stores the associated IOMMU
domains. This patch introduces a helper function to do domain to PASID
look up. It will be used by TLB flush and device-PASID attach verification.
Signed-off-by: Jacob Pan
---
drivers/iommu/iommu.c | 22
both DMA requests with and without
PASIDs are mapped identically, there is no change to how DMA APIs are
used after the kernel PASID is enabled.
Link: https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/idxd.h | 1 -
drivers/dma
introduces a driver facing API that enables DMA API
PASID usage. Once enabled, device drivers can continue to use DMA APIs as
is. There is no difference in dma_handle between without PASID and with
PASID.
Signed-off-by: Jacob Pan
---
drivers/iommu/dma-iommu.c | 114
nd_device parameters
- Use IOMMU specific data instead of struct device to store PASID
info
*** SUBJECT HERE ***
*** BLURB HERE ***
Jacob Pan (6):
iommu: Add a per domain PASID for DMA API
iommu: Add a helper to do PASID lookup from domain
iommu/vt-d: Implement domain ops
DMA requests tagged with PASID can target individual IOMMU domains.
Introduce a domain-wide PASID for DMA API, it will be used on the same
mapping as legacy DMA without PASID. Let it be IOVA or PA in case of
identity domain.
Signed-off-by: Jacob Pan
---
include/linux/iommu.h | 2 ++
1 file
and device TLB invalidations
This patch add attach_dev_pasid functions to the default domain ops which
is used by DMA and identity domain types. It could be extended to support
other domain types whenever necessary.
Signed-off-by: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iommu/intel
Hi Jason,
On Mon, 16 May 2022 15:06:28 -0300, Jason Gunthorpe wrote:
> Unrelated, but when we are in the special secure IOMMU modes, do we
> force ATS off? Specifically does the IOMMU reject TLPs that are marked
> as translated?
Yes, VT-d context entry has a Device TLB Enable bit, if 0, it
Hi Jason,
On Wed, 11 May 2022 14:00:25 -0300, Jason Gunthorpe wrote:
> On Wed, May 11, 2022 at 10:02:16AM -0700, Jacob Pan wrote:
> > > > If not global, perhaps we could have a list of pasids (e.g. xarray)
> > > > attached to the device_domain_info. The TLB flush
Hi Jason,
On Wed, 11 May 2022 13:12:37 -0300, Jason Gunthorpe wrote:
> On Wed, May 11, 2022 at 08:35:18AM -0700, Jacob Pan wrote:
>
> > > Huh? The intel driver shares the same ops between UNMANAGED and DMA -
> > > and in general I do not think we should be putting speci
Hi Jason,
On Wed, 11 May 2022 08:54:27 -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 05:23:09PM -0700, Jacob Pan wrote:
>
> > > > diff --git a/include/linux/intel-iommu.h
> > > > b/include/linux/intel-iommu.h index 5af24befc9f1..55845a8c4f4d
> >
Hi Jason,
On Tue, 10 May 2022 20:28:04 -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 02:07:02PM -0700, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
&g
Hi Jason,
On Tue, 10 May 2022 20:21:21 -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> > +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> > + str
both DMA requests with and without
PASIDs are mapped identically, there is no change to how DMA APIs are
used after the kernel PASID is enabled.
Link: https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/idxd.h | 1 -
drivers/dma
introduces a driver facing API that enables DMA API
PASID usage. Once enabled, device drivers can continue to use DMA APIs as
is. There is no difference in dma_handle between without PASID and with
PASID.
Signed-off-by: Jacob Pan
---
drivers/iommu/dma-iommu.c | 107
Supervisor PASID for SVA/SVM is no longer supported, delete the unused
flag.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 2 +-
include/linux/intel-svm.h | 13 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu
ed the DMA API only IOMMU op.
- Removed supervisor SVA support in VT-d
- Removed unused sva_bind_device parameters
- Use IOMMU specific data instead of struct device to store PASID
info
Jacob Pan (4):
iommu/vt-d: Implement domain ops for attach_dev_pasid
iommu:
and device TLB invalidations
This patch add attach_dev_pasid functions to the default domain ops which
is used by DMA and identity domain types. It could be extended to support
other domain types whenever necessary.
Signed-off-by: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iommu/intel
Hi BaoLu,
On Sun, 1 May 2022 19:24:33 +0800, Lu Baolu
wrote:
> The IOMMU force snooping capability is not required to be consistent
> among all the IOMMUs anymore. Remove force snooping capability check
> in the IOMMU hot-add path and domain_update_iommu_snooping() becomes
> a dead code now.
>
Hi BaoLu,
On Sun, 1 May 2022 19:24:32 +0800, Lu Baolu
wrote:
> As domain->force_snooping only impacts the devices attached with the
> domain, there's no need to check against all IOMMU units. At the same
> time, for a brand new domain (hasn't been attached to any device), the
> force_snooping
Hi Alex,
Thanks for doing this, really helps to catch up the current state. Please
see my comments inline.
On Fri, 22 Apr 2022 16:06:07 -0400, Alex Deucher
wrote:
> Add preliminary documentation for AMD IOMMU and combine
> with the existing Intel IOMMU documentation and clean
> up and
Hi Jean-Philippe,
On Mon, 25 Apr 2022 17:13:02 +0100, Jean-Philippe Brucker
wrote:
> Hi Jacob,
>
> On Mon, Apr 25, 2022 at 08:34:44AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Mon, 25 Apr 2022 15:26:40 +0100, Jean-Philippe Brucker
> > wrote:
Hi Jean-Philippe,
On Mon, 25 Apr 2022 15:26:40 +0100, Jean-Philippe Brucker
wrote:
> On Mon, Apr 25, 2022 at 07:18:36AM -0700, Dave Hansen wrote:
> > On 4/25/22 06:53, Jean-Philippe Brucker wrote:
> > > On Sat, Apr 23, 2022 at 07:13:39PM +0800, zhangfei@foxmail.com
> > > wrote:
> >
Hi zhangfei@foxmail.com,
On Sat, 16 Apr 2022 09:43:07 +0800, "zhangfei@foxmail.com"
wrote:
> On 2022/4/16 上午5:00, Jacob Pan wrote:
> > Hi zhangfei@foxmail.com,
> >
> > On Fri, 15 Apr 2022 19:52:03 +0800, "zhangfei@foxmail.com"
> &g
Hi Kevin,
On Mon, 18 Apr 2022 06:34:19 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Saturday, April 16, 2022 5:00 AM
> >
> > Hi zhangfei@foxmail.com,
> >
> > On Fri, 15 Apr 2022 19:52:03 +0800, "zhangfei@foxmail.com&q
Hi zhangfei@foxmail.com,
On Fri, 15 Apr 2022 19:52:03 +0800, "zhangfei@foxmail.com"
wrote:
> >>> A PASID might be still used even though it is freed on mm exit.
> >>>
> >>> process A:
> >>> sva_bind();
> >>> ioasid_alloc() = N; // Get PASID N for the mm
> >>> fork(): // spawn
Hi Lu,
On Tue, 29 Mar 2022 13:37:57 +0800, Lu Baolu
wrote:
> The existing iommu SVA interfaces are implemented by calling the SVA
> specific iommu ops provided by the IOMMU drivers. There's no need for
> any SVA specific ops in iommu_ops vector anymore as we can achieve
> this through the
Hi BaoLu,
On Tue, 29 Mar 2022 13:37:52 +0800, Lu Baolu
wrote:
> Add a new iommu domain type IOMMU_DOMAIN_SVA to represent an I/O page
> table which is shared from CPU host VA. Add some helpers to get and
> put an SVA domain and implement SVA domain life cycle management.
>
> Signed-off-by: Lu
Hi BaoLu,
On Tue, 29 Mar 2022 13:37:50 +0800, Lu Baolu
wrote:
> Use this field to save the pasid/ssid bits that a device is able to
> support with its IOMMU hardware. It is a generic attribute of a device
> and lifting it into the per-device dev_iommu struct makes it possible
> to allocate a
Hi Kevin,
On Fri, 18 Mar 2022 06:16:58 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > In-kernel DMA with PASID should use DMA API now, remove supervisor
> > PASID
> > SVA support. Remove spe
Hi Kevin,
On Fri, 18 Mar 2022 06:10:40 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > The current in-kernel supervisor PASID support is based on the SVM/SVA
> > machinery in SVA lib. The binding betwe
Hi BaoLu,
On Fri, 18 Mar 2022 20:43:54 +0800, Lu Baolu
wrote:
> On 2022/3/15 13:07, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some modern devices s
Hi Kevin,
On Fri, 18 Mar 2022 05:33:38 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Thursday, March 17, 2022 5:02 AM
> >
> > Hi Kevin,
> >
> > On Wed, 16 Mar 2022 07:41:34 +, "Tian, Kevin"
> > wrote:
> >
Hi Kevin,
On Wed, 16 Mar 2022 07:54:19 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > With the availability of a generic device-PASID-domain attachment API,
> > there's no need to special case RID2PASID
Hi Jason,
On Thu, 17 Mar 2022 10:23:08 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 16, 2022 at 05:49:59PM -0700, Jacob Pan wrote:
>
> > > I would expect real applications will try to use the same PASID for
> > > the same IOVA map to optimize IOTLB caching.
> >
Hi Jason,
On Wed, 16 Mar 2022 19:15:50 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 16, 2022 at 01:50:04PM -0700, Jacob Pan wrote:
>
> > I guess a list of (device, pasid) tuples as you suggested could work
> > but it will have duplicated device entries since each device could
Hi Kevin,
On Wed, 16 Mar 2022 07:41:34 +, "Tian, Kevin"
wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 15, 2022 10:33 PM
> >
> > On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > > + /*
> > > + * Each domain co
Hi Kevin,
On Wed, 16 Mar 2022 07:39:09 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> > +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> > + stru
Hi Jason,
On Tue, 15 Mar 2022 20:04:57 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 15, 2022 at 03:36:20PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Tue, 15 Mar 2022 11:33:22 -0300, Jason Gunthorpe
> > wrote:
> > > On Mon, Mar 14, 2022
Hi Jason,
On Tue, 15 Mar 2022 11:33:22 -0300, Jason Gunthorpe wrote:
> On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > + /*
> > +* Each domain could have multiple devices attached with
> > shared or per
> > +* device PASIDs. At the domain lev
Hi Kevin,
On Tue, 15 Mar 2022 10:33:08 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > On VT-d platforms with scalable mode enabled, devices issue DMA requests
> > with PASID need to attach to t
Hi Jason,
On Tue, 15 Mar 2022 14:05:07 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 15, 2022 at 09:31:35AM -0700, Jacob Pan wrote:
>
> > > IMHO it is a device mis-design of IDXD to require all DMA be PASID
> > > tagged. Devices should be able to do DMA on their RID wh
Hi Jason,
On Tue, 15 Mar 2022 11:35:35 -0300, Jason Gunthorpe wrote:
> On Mon, Mar 14, 2022 at 10:07:09PM -0700, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
&g
Hi Jason,
On Tue, 15 Mar 2022 11:22:16 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 15, 2022 at 11:16:41AM +, Robin Murphy wrote:
> > On 2022-03-15 05:07, Jacob Pan wrote:
> > > DMA mapping API is the de facto standard for in-kernel DMA. It
> > > operates on a
Hi Kevin,
On Tue, 15 Mar 2022 11:49:57 +, "Tian, Kevin"
wrote:
> > From: Jean-Philippe Brucker
> > Sent: Tuesday, March 15, 2022 7:27 PM
> >
> > On Mon, Mar 14, 2022 at 10:07:06PM -0700, Jacob Pan wrote:
> > > From: Lu Baolu
> > >
>
Hi Kevin,
On Tue, 15 Mar 2022 08:16:59 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > Some modern accelerators such as Intel's Data Streaming Accelerator
> > (DSA) require PASID in DMA requests to be
-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 4 +++-
include/linux/iommu.h | 13 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 50666d250b36..881f8361eca2 100644
--- a/drivers/iommu/intel
With the availability of a generic device-PASID-domain attachment API,
there's no need to special case RID2PASID. Use the API to replace
duplicated code.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff
In-kernel DMA with PASID should use DMA API now, remove supervisor PASID
SVA support. Remove special cases in bind mm and page request service.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 42 ---
1 file changed, 8 insertions(+), 34 deletions
both DMA requests with and without
PASIDs are mapped identically, there is no change to how DMA APIs are
used after the kernel PASID is enabled.
Link: https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/idxd.h | 1 -
drivers/dma
uot; flags.
Signed-off-by: Dave Jiang
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/cdev.c | 4 ++--
drivers/dma/idxd/idxd.h | 6 ++
drivers/dma/idxd/init.c | 30 ++
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/idxd/cdev.c b/driver
and device TLB invalidations
This patch extends DMAR domain and device domain info with xarrays to
track per domain and per device PASIDs. It provides the flexibility to
be used beyond DMA API PASID support.
Signed-off-by: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 194
No one is using drvdata for sva_bind_device after kernel SVA support is
removed from VT-d driver. Remove the drvdata parameter as well.
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/cdev.c | 2 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
drivers/iommu/arm
devices
attached to a given domain.
This patch introduces a new IOMMU op which support device, PASID, and
IOMMU domain attachment. The immediate use case is for PASID capable
devices to perform DMA under DMA APIs.
Signed-off-by: Lu Baolu
Signed-off-by: Jacob Pan
---
include/linux/iommu.h | 6
introduces a driver facing API that enables DMA API
PASID usage. Once enabled, device drivers can continue to use DMA APIs as
is. There is no difference in dma_handle between without PASID and with
PASID.
Signed-off-by: Jacob Pan
---
drivers/iommu/dma-iommu.c | 65
unused sva_bind_device parameters
- Use IOMMU specific data instead of struct device to store PASID
info
Jacob Pan (6):
iommu/vt-d: Implement device_pasid domain attach ops
iommu/vt-d: Use device_pasid attach op for RID2PASID
iommu: Add PASID support for DMA mapping API users
Hi BaoLu,
On Mon, 7 Feb 2022 14:41:41 +0800, Lu Baolu
wrote:
>
> - if (dev && domain_context_mapping(domain, dev)) {
> - dev_err(dev, "Domain context map failed\n");
> - dmar_remove_one_dev_info(dev);
> - return NULL;
> - }
> + /* Setup the
On Wed, 9 Feb 2022 19:16:14 -0800, Jacob Pan
wrote:
> Hi Fenghua,
>
> On Mon, 7 Feb 2022 15:02:48 -0800, Fenghua Yu
> wrote:
>
> > @@ -1047,8 +1040,6 @@ struct iommu_sva *intel_svm_bind(struct device
> > *dev, struct mm_struct *mm, void }
> >
> >
Hi Fenghua,
On Mon, 7 Feb 2022 15:02:48 -0800, Fenghua Yu wrote:
> @@ -1047,8 +1040,6 @@ struct iommu_sva *intel_svm_bind(struct device
> *dev, struct mm_struct *mm, void }
>
> sva = intel_svm_bind_mm(iommu, dev, mm, flags);
> - if (IS_ERR_OR_NULL(sva))
> -
Hi Joerg,
On Thu, 3 Feb 2022 09:25:58 +0100, Joerg Roedel wrote:
> On Tue, Feb 01, 2022 at 11:19:18AM -0800, Jacob Pan wrote:
> > Do you mean having an IRQ remapping notifier regardless IOMMU-API is
> > enabled, right?
> > It make sense, I will give it a try.
>
>
Hi BaoLu,
On Mon, 7 Feb 2022 14:41:41 +0800, Lu Baolu
wrote:
> static void intel_iommu_release_device(struct device *dev)
> {
> - struct intel_iommu *iommu;
> -
> - iommu = device_to_iommu(dev, NULL, NULL);
> - if (!iommu)
> - return;
> -
> -
Hi Joerg,
On Mon, 31 Jan 2022 16:52:10 +0100, Joerg Roedel wrote:
> On Mon, Jan 31, 2022 at 01:53:06PM +, Robin Murphy wrote:
> > Indeed I very nearly asked whether we couldn't just call these from
> > intel_iommu_{probe,release}_device() directly, but it looks like they
> > also interact
Hi Joerg,
On Sun, 30 Jan 2022 08:43:19 +0100, Joerg Roedel wrote:
> Hi Jacob, Baolu,
>
> On Fri, Jan 28, 2022 at 11:10:01AM +0800, Lu Baolu wrote:
> > During PCI bus rescan, adding new devices involve two notifiers.
> > 1. dmar_pci_bus_notifier()
> > 2. iommu_bus_notifier()
> > The current
Hi all,
Just wondering if there are any other comments? This fixes a
regression that can cause system hang.
On Fri, 14 Jan 2022 00:21:10 -0800, Jacob Pan
wrote:
> During PCI bus rescan, adding new devices involve two notifiers.
> 1. dmar_pci_bus_notifier()
> 2. iommu_bus
llowing:
1. dmar_pci_bus_add_dev()
2. iommu_probe_device()
3. iommu_release_device()
4. dmar_pci_bus_remove_dev()
Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Reported-by: Zhang, Bernice
Suggested-by: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iom
Hi Lu,
On Fri, 14 Jan 2022 11:12:45 +0800, Lu Baolu
wrote:
> On 1/14/22 11:11 AM, Jacob Pan wrote:
> > On Fri, 14 Jan 2022 08:58:53 +0800, Lu Baolu
> > wrote:
> >
> >> Hi Jacob,
> >>
> >> On 1/13/22 9:23 PM, Jacob Pan wrote:
> >&g
Hi BaoLu,
On Fri, 14 Jan 2022 08:58:53 +0800, Lu Baolu
wrote:
> Hi Jacob,
>
> On 1/13/22 9:23 PM, Jacob Pan wrote:
> > During PCI bus rescan, adding new devices involve two notifiers.
> > 1. dmar_pci_bus_notifier()
> > 2. iommu_bus_notifier()
> > The cur
g a higher priority for
dmar_pci_bus_notifier. DRHD search for a new device will find the
correct IOMMU.
Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Reported-by: Zhang, Bernice
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/dmar.c | 2 +-
1 file change
Hi Jason,
On Fri, 10 Dec 2021 13:48:48 -0400, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 09:50:25AM -0800, Jacob Pan wrote:
>
> > > Tying pasid to an iommu_domain is not a good idea. An iommu_domain
> > > represents an I/O address translation table. It could be at
Hi Jason,
On Fri, 10 Dec 2021 08:31:09 -0400, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 09:06:24AM +, Jean-Philippe Brucker wrote:
> > On Thu, Dec 09, 2021 at 10:14:04AM -0800, Jacob Pan wrote:
> > > > This looks like we're just one step away from d
Hi Lu,
On Fri, 10 Dec 2021 14:46:32 +0800, Lu Baolu
wrote:
> On 2021/12/10 7:21, Jacob Pan wrote:
> > On Thu, 9 Dec 2021 10:32:43 +0800, Lu Baolu
> > wrote:
> >
> >> On 12/9/21 3:16 AM, Jacob Pan wrote:
> >>> Hi Jason,
> >>>
&g
Hi Lu,
On Thu, 9 Dec 2021 10:32:43 +0800, Lu Baolu
wrote:
> On 12/9/21 3:16 AM, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 8 Dec 2021 09:22:55 -0400, Jason Gunthorpe
> > wrote:
> >> On Tue, Dec 07, 2021 at 05:47:13AM -0800, Jacob Pan wrote:
> &g
Hi Kevin,
On Thu, 9 Dec 2021 01:48:09 +, "Tian, Kevin"
wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, December 9, 2021 1:51 AM
> >
> > > > > + /*
> > > > > + * Try to enable both in-kernel and user DMA request
> > > > > with PASID.
> > > > > + * PASID is supported
Hi Jean-Philippe,
On Thu, 9 Dec 2021 11:03:23 +, Jean-Philippe Brucker
wrote:
> Hi Jacob,
>
> On Tue, Dec 07, 2021 at 05:47:11AM -0800, Jacob Pan wrote:
> > In-kernel DMA is managed by DMA mapping APIs, which supports per device
> > addressing mode fo
Hi Ashok,
On Thu, 9 Dec 2021 08:57:15 -0800, "Raj, Ashok" wrote:
> > Prefixes is disabled
> > - Root Complexes may optionally support TLPs with PASID TLP Prefixes.
> > The mechanism used to detect whether a Root Complex supports the PASID
> > TLP Prefix is implementation specific
>
> Isn't
Hi Lu,
On Thu, 9 Dec 2021 10:21:38 +0800, Lu Baolu
wrote:
> On 12/9/21 9:56 AM, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Thursday, December 9, 2021 2:50 AM
> >>
> >>> Can a device issue DMA requests with PASID even there's no syste
Hi Jason,
On Wed, 8 Dec 2021 16:30:22 -0400, Jason Gunthorpe wrote:
> On Wed, Dec 08, 2021 at 11:55:16AM -0800, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe
> > wrote:
> > > > This patch utilizes
Hi Jason,
On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe wrote:
> > This patch utilizes iommu_enable_pasid_dma() to enable DSA to perform
> > DMA requests with PASID under the same mapping managed by DMA mapping
> > API. In addition, SVA-related bits for kernel DMA are removed. As a
> >
Hi Jason,
On Wed, 8 Dec 2021 09:22:55 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 07, 2021 at 05:47:13AM -0800, Jacob Pan wrote:
> > Between DMA requests with and without PASID (legacy), DMA mapping APIs
> > are used indiscriminately on a device. Therefore, we shou
Hi Lu,
On Wed, 8 Dec 2021 10:31:36 +0800, Lu Baolu
wrote:
> Hi Jacob,
>
> On 12/7/21 9:47 PM, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some
Hi Jason,
Thanks for the quick review.
On Wed, 8 Dec 2021 09:10:38 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 07, 2021 at 05:47:10AM -0800, Jacob Pan wrote:
> > Modern accelerators such as Intel's Data Streaming Accelerator (DSA) can
> > perform DMA requests with PASID, w
Hi Vinod,
On Wed, 8 Dec 2021 10:26:22 +0530, Vinod Koul wrote:
> Pls resend collecting acks. I dont have this in my queue
Will do. Sorry I missed the dmaengine list.
Thanks,
Jacob
___
iommu mailing list
iommu@lists.linux-foundation.org
. This also serves as a flag indicating
whether PASID is being used for the device to perform in-kernel DMA.
Signed-off-by: Jacob Pan
---
drivers/iommu/dma-iommu.c | 71 +++
include/linux/device.h| 1 +
include/linux/dma-iommu.h | 7
include/linux/iommu.h
will fit the bill.
Signed-off-by: Jacob Pan
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
drivers/iommu/intel/iommu.c | 4 ++--
drivers/iommu/intel/pasid.h | 3 +--
drivers/iommu/intel/svm.c | 2 +-
drivers/iommu/ioasid.c
.
Once this set is accepted, more cleanup patches will follow. The plan is to
remove the usage of sva_bind_device() for in-kernel usages. Removing page
requests and other special cases around kernel SVA in VT-d driver.
Jacob Pan (4):
ioasid: Reserve a global PASID for in-kernel DMA
iommu
is also on a
per-domain basis; whereas device TLB flush is per device. Note that
IOTLBs are used even when devices are in pass-through mode. ATS is
enabled device-wide, but the device drivers can choose to manage ATS at
per PASID level whenever control is available.
Signed-off-by: Jacob Pan
: https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
Signed-off-by: Jacob Pan
---
.../admin-guide/kernel-parameters.txt | 6 --
drivers/dma/Kconfig | 10
drivers/dma/idxd/idxd.h | 1 -
drivers/dma/idxd/init.c
Hi Jason,
On Tue, 19 Oct 2021 13:57:47 -0300, Jason Gunthorpe wrote:
> On Tue, Oct 19, 2021 at 09:57:34AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Fri, 15 Oct 2021 08:18:07 -0300, Jason Gunthorpe
> > wrote:
> > > On Fri, Oct 15, 2021
Hi Jason,
On Fri, 15 Oct 2021 08:18:07 -0300, Jason Gunthorpe wrote:
> On Fri, Oct 15, 2021 at 09:18:06AM +, Liu, Yi L wrote:
>
> > > Acquire from the xarray is
> > >rcu_lock()
> > >ioas = xa_load()
> > >if (ioas)
> > > if (down_read_trylock(>destroying_lock))
> >
>
1 - 100 of 1247 matches
Mail list logo
