On Tue, Mar 30, 2021 at 10:11:45AM +0800, Lu Baolu wrote:
> drivers/iommu/intel/pasid.h | 1 +
> drivers/iommu/intel/iommu.c | 11 ++-
> drivers/iommu/intel/pasid.c | 16
> 3 files changed, 27 insertions(+), 1 deletion(-)
Applied, thanks.
On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote:
> Jean-Philippe Brucker (10):
> iommu: Fix comment for struct iommu_fwspec
> iommu/arm-smmu-v3: Use device properties for pasid-num-bits
> iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
> iommu/vt-d:
Hi Eric,
On 2021/2/24 5:06, Eric Auger wrote:
+/*
+ * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 18,
+ * struct vfio_iommu_type1_set_pasid_table)
+ *
+ * The SET operation passes a PASID table to the host while the
+ * UNSET operation detaches the one
On Wed, Mar 31, 2021 at 11:16:45AM +0800, Chunyan Zhang wrote:
> drivers/iommu/sprd-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
command and they're not used by the driver. Remove them.
We can add them back if we're going to use PREFETCH_ADDR in the future.
Signed-off-by: Zenghui Yu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 --
On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote:
> Diffstat:
> arch/powerpc/include/asm/fsl_pamu_stash.h | 12
> drivers/gpu/drm/msm/adreno/adreno_gpu.c |5
> drivers/iommu/amd/iommu.c | 23
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75
On Fri, Apr 02, 2021 at 04:33:08PM +0200, Christoph Hellwig wrote:
> Hi,
>
> this series cleans up a few random bits in the AMD IOMMU driver.
>
> Diffstat:
> arch/x86/events/amd/iommu.c|1
> arch/x86/events/amd/iommu.h| 19 --
>
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest
On Mon, Mar 01, 2021 at 08:12:18PM +0800, John Garry wrote:
> The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
> offlined.
>
> Let's move it to core code, so everyone can take advantage.
>
> Also correct a code comment.
>
> Based on v5.12-rc1. Tested on arm64 only.
>
On 07/04/2021 09:04, Joerg Roedel wrote:
On Mon, Mar 01, 2021 at 08:12:18PM +0800, John Garry wrote:
The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
offlined.
Let's move it to core code, so everyone can take advantage.
Also correct a code comment.
Based on
On Sat, Mar 20, 2021 at 10:41:56AM +0800, Lu Baolu wrote:
> drivers/iommu/intel/svm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Tue, Mar 23, 2021 at 09:05:55AM +0800, Lu Baolu wrote:
> Lu Baolu (5):
> iommu/vt-d: Remove unused dma map/unmap trace events
> iommu/vt-d: Remove svm_dev_ops
> iommu/vt-d: Remove SVM_FLAG_PRIVATE_PASID
> iommu/vt-d: Remove unused function declarations
> iommu/vt-d: Make unnecessarily
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:43 PM
>
> On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
>
> > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> have
> > > /dev/ioasid. That all belongs in the iosaid side.
> > >
> > > I know they have
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote:
> John Garry (4):
> iova: Add CPU hotplug handler to flush rcaches
> iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining
> iommu: Delete iommu_dma_free_cpu_cached_iovas()
> iommu: Stop exporting free_iova_fast()
>
>
On Sat, Mar 20, 2021 at 10:09:16AM +0800, Lu Baolu wrote:
> drivers/iommu/intel/pasid.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, Mar 25, 2021 at 09:43:45AM +, Will Deacon wrote:
> Urgh, I must say I much preferred these things being exclusive, but this
> looks like a necessary fix:
>
> Acked-by: Will Deacon
Applied for v5.12.
___
iommu mailing list
On Fri, Mar 26, 2021 at 11:23:36AM +0800, Yong Wu wrote:
> This patch only adds support for building the IOMMU-v1 driver as module.
> Correspondingly switch the config to tristate and update the iommu_ops's
> owner to THIS_MODULE.
>
> Signed-off-by: Yong Wu
Applied both, thanks.
Hi Baolu,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, April 2, 2021 12:44 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; iommu@lists.linux-foundation.org;
> linux-ker...@vger.kernel.org
> Cc: baolu...@linux.intel.com;
On Tue, Apr 06, 2021 at 02:02:26PM -0700, isa...@codeaurora.org wrote:
> On 2021-04-06 05:15, Will Deacon wrote:
> > On Mon, Apr 05, 2021 at 12:11:09PM -0700, Isaac J. Manjarres wrote:
> > > Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> > > format.
> > >
> > > Signed-off-by:
On Tue, Mar 23, 2021 at 02:06:19PM -0700, Nadav Amit wrote:
> From: Nadav Amit
>
> Currently, IOMMU invalidations and device-IOTLB invalidations using
> AMD IOMMU fall back to full address-space invalidation if more than a
> single page need to be flushed.
>
> Full flushes are especially
Hi Paul,
On Thu, Mar 18, 2021 at 10:20:16AM +0100, Paul Menzel wrote:
> Jörg, I know you are probably busy, but the patch was applied to the stable
> series (v5.11.7). There are still too many question open regarding the
> patch, and Suravee has not yet addressed the comments. It’d be great, if
On Sun, Mar 28, 2021 at 09:40:09AM +0200, Sven Peter wrote:
> Apple's new SoCs use iommus for almost all peripherals. These Device
> Address Resolution Tables must be setup before these peripherals can
> act as DMA masters.
>
> Signed-off-by: Sven Peter
> ---
> MAINTAINERS
On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> Apple's DART iommu uses a pagetable format that shares some
> similarities with the ones already implemented by io-pgtable.c.
> Add a new format variant to support the required differences
> so that we don't have to duplicate the
On Tue, Apr 06, 2021 at 02:07:41PM -0700, isa...@codeaurora.org wrote:
> On 2021-04-06 04:57, Will Deacon wrote:
> > On Mon, Apr 05, 2021 at 12:11:03PM -0700, Isaac J. Manjarres wrote:
> > > Mapping memory into io-pgtables follows the same semantics
> > > that unmapping memory used to follow (i.e.
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 8:43 PM
> >
> > On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
> >
> > > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> > have
> > > >
On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
> > Because if you don't then we enter insane world where a PASID is being
> > created under /dev/ioasid but its translation path flows through setup
> > done by VFIO and the whole user API becomes an incomprehensible mess.
> >
> > How
The IOMMU driver calculates the guest addressability for a DMA request
based on the value of the mgaw reported from the IOMMU. However, this
is a fused value and as mentioned in the spec, the guest width
should be calculated based on the minimum of supported adjusted guest
address width (SAGAW)
> On Apr 7, 2021, at 3:01 AM, Joerg Roedel wrote:
>
> On Tue, Mar 23, 2021 at 02:06:19PM -0700, Nadav Amit wrote:
>> From: Nadav Amit
>>
>> Currently, IOMMU invalidations and device-IOTLB invalidations using
>> AMD IOMMU fall back to full address-space invalidation if more than a
>> single
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> btw this discussion was raised when discussing the I/O page fault handling
> process. Currently the IOMMU layer implements a per-device fault reporting
> mechanism, which requires VFIO to register a handler to receive all faults
> on
On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
> * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> No operation available since we don't know what the device and IOMMU
> capabilities are.
>
> * Attach the handle to a VF. With VFIO that would be
>
Hi Lu,
On Apr 6, 2021, at 6:43 PM, Lu Baolu
mailto:baolu...@linux.intel.com>> wrote:
Hi Saeed,
On 4/7/21 12:35 AM, Saeed Mirzamohammadi wrote:
The IOMMU driver calculates the guest addressability for a DMA request
based on the value of the mgaw reported from the IOMMU. However, this
is a
> From: Jason Gunthorpe
> Sent: Wednesday, April 7, 2021 8:21 PM
>
> On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
>
> > > Because if you don't then we enter insane world where a PASID is being
> > > created under /dev/ioasid but its translation path flows through setup
> > >
On 4/8/21 2:40 AM, Saeed Mirzamohammadi wrote:
The IOMMU driver calculates the guest addressability for a DMA request
based on the value of the mgaw reported from the IOMMU. However, this
is a fused value and as mentioned in the spec, the guest width
should be calculated based on the minimum of
On 2021-04-07 02:57, Will Deacon wrote:
On Tue, Apr 06, 2021 at 02:02:26PM -0700, isa...@codeaurora.org wrote:
On 2021-04-06 05:15, Will Deacon wrote:
> On Mon, Apr 05, 2021 at 12:11:09PM -0700, Isaac J. Manjarres wrote:
> > Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> >
Implement the unmap_pages() callback for the ARM v7s io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
Mapping memory into io-pgtables follows the same semantics
that unmapping memory used to follow (i.e. a buffer will be
mapped one page block per call to the io-pgtable code). This
means that it can be optimized in the same way that unmapping
memory was, so add a map_pages() callback to the
Implement the map_pages() callback for the ARM v7s io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
Implement the map_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm.c | 42 ++
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c
From: Will Deacon
Avoid the potential for shifting values by amounts greater than the
width of their type by using a bitmap to compute page size in
iommu_pgsize().
Signed-off-by: Will Deacon
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/iommu.c | 31 ---
1
The PTE methods currently operate on a single entry. In preparation
for manipulating multiple PTEs in one map or unmap call, allow them
to handle multiple PTEs.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c | 78
Implement the unmap_pages() callback for the ARM SMMU driver
to allow calls from iommu_unmap to unmap multiple pages of
the same size in one call. Also, remove the unmap() callback
for the SMMU driver, as it will no longer be used.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
From: Will Deacon
Extend iommu_pgsize() to populate an optional 'count' parameter so that
we can direct unmapping operation to the ->unmap_pages callback if it
has been provided by the driver.
Signed-off-by: Will Deacon
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/iommu.c | 60
Implement the unmap_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/io-pgtable-arm.c | 70 ++
1 file changed, 45 insertions(+), 25 deletions(-)
diff --git
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can
call into the io-pgtable code, to map a physically contiguous
rnage of pages of the same size.
For IOMMU drivers that do not specify a map_pages() callback,
the existing logic of
From: Will Deacon
The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.
Subsequent
Since iommu_pgsize can calculate how many pages of the
same size can be mapped/unmapped before the next largest
page size boundary, add support for invoking an IOMMU
driver's map_pages() callback, if it provides one.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
Implement the map_pages() callback for the ARM SMMU driver
to allow calls from iommu_map to map multiple pages of
the same size in one call. Also, remove the map() callback
for the ARM SMMU driver, as it will no longer be used.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
Hi Longpeng,
On 4/7/21 2:35 PM, Longpeng (Mike, Cloud Infrastructure Service Product
Dept.) wrote:
Hi Baolu,
-Original Message-
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Friday, April 2, 2021 12:44 PM
To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
;
When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within the buffer. For every block that
is unmapped, the IOMMU framework will call into the IOMMU driver, and
then the
The io-pgtable code expects to operate on a single block or
granule of memory that is supported by the IOMMU hardware when
unmapping memory.
This means that when a large buffer that consists of multiple
such blocks is unmapped, the io-pgtable code will walk the page
tables to the correct level to
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.
For IOMMU drivers that do not specify an unmap_pages() callback,
the existing logic of
On Wed, 7 Apr 2021 16:44:48 +0800, Zenghui Yu wrote:
> Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
> command and they're not used by the driver. Remove them.
>
> We can add them back if we're going to use PREFETCH_ADDR in the future.
Applied to will
On Wed, Apr 07, 2021 at 09:58:05AM +0800, Lu Baolu wrote:
> I've ever tried to implement a bus iommu_ops for mdev devices.
>
> https://lore.kernel.org/lkml/20201030045809.957927-1-baolu...@linux.intel.com/
>
> Any comments?
You still have the symbol_get, so something continues to be wrong with
54 matches
Mail list logo
