Hi Jean,
On 12/19/19 5:30 PM, Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main DMA
Hi Jean,
On 12/19/19 5:30 PM, Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
> descriptors
On a system with an Intel PCIe port configured as a nvme host device, iommu
initialization fails with
DMAR: Device scope type does not match for :80:00.0
This is because the DMAR table reports this device as having scope 2
(ACPI_DMAR_SCOPE_TYPE_BRIDGE):
but the device has a type 0 PCI
> On Dec 20, 2019, at 03:15, Deucher, Alexander
> wrote:
>
>> -Original Message-
>> From: Kai-Heng Feng
>> Sent: Wednesday, December 18, 2019 12:45 PM
>> To: Joerg Roedel
>> Cc: Christoph Hellwig ; Deucher, Alexander
>> ; iommu@lists.linux-foundation.org; Kernel
>> development list
On Mon, Dec 09, 2019 at 11:13:46PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all DMA to and from guest has to use shared
> (un-encrypted) pages. SEV uses SWIOTLB to make this happen
> without requiring changes to device drivers. However,
> depending on workload being run, the
IOVA might not be always 4KB aligned. So tegra_smmu_iova_to_phys
function needs to add on the lower 12-bit offset from input iova.
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-smmu.c
Hi all,
This series of patches are some small fixes for tegra-smmu, mainly
tested Tegra210 with downstream kernel. As we only enabled limited
clients for Tegra210 on mainline tree, I am not sure how critical
these fixes are, so not CCing stable tree.
Nicolin Chen (4):
memory: tegra: Correct
When testing with ethernet downloading, "EMEM address decode error"
happens due to race condition between map() and unmap() functions.
This patch adds a spin lock to protect content within as->[count]
and as->pts[pde] references, since a function call might be atomic.
Signed-off-by: Nicolin Chen
According to Tegra X1 (Tegra210) TRM, the reset value of xusb_hostr
field (bit [7:0]) should be 0x7a. So this patch simply corrects it.
Signed-off-by: Nicolin Chen
---
drivers/memory/tegra/tegra210.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
PAGE_SHIFT and PAGE_MASK are defined corresponding to the page size
for CPU virtual addresses, which means PAGE_SHIFT could be a number
other than 12, but tegra-smmu maintains fixed 4KB IOVA pages and has
fixed [21:12] bit range for PTE entries.
So this patch replaces all PAGE_SHIFT/PAGE_MASK
> -Original Message-
> From: Kai-Heng Feng
> Sent: Wednesday, December 18, 2019 12:45 PM
> To: Joerg Roedel
> Cc: Christoph Hellwig ; Deucher, Alexander
> ; iommu@lists.linux-foundation.org; Kernel
> development list
> Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge
>
On Thu, Dec 19, 2019 at 12:58:15PM -0700, Jordan Crouse wrote:
> On Thu, Dec 19, 2019 at 06:44:46PM +0530, Sharat Masetty wrote:
> > +
> > + /*
> > +* CNTL1 is used to specify SCID for (CP, TP, VFD, CCU and UBWC
> > +* FLAG cache) GPU blocks. This value will be passed along with
> >
On Thu, Dec 19, 2019 at 06:44:46PM +0530, Sharat Masetty wrote:
> The last level system cache can be partitioned to 32 different slices
> of which GPU has two slices preallocated. One slice is used for caching GPU
> buffers and the other slice is used for caching the GPU SMMU pagetables.
> This
On Thu, Dec 19, 2019 at 06:44:45PM +0530, Sharat Masetty wrote:
> Allow different Adreno targets the ability to pass
> specific mmu features to the generic layers. This will
> help conditionally configure certain iommu features for
> certain Adreno targets.
>
> Also Add a few simple support
Support for SSID will require allocating context descriptor tables. Move
the context descriptor allocation to separate functions.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 57
Since commit 518a2f1925c3 ("dma-mapping: zero memory returned from
dma_alloc_*"), dma_alloc_* always initializes memory to zero, so there
is no need to use dma_zalloc_* or pass the __GFP_ZERO flag anymore.
The flag was introduced by commit 04fa26c71be5 ("iommu/arm-smmu: Convert
DMA buffer
At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
page directory per device. However SMMUv3 allows more than one address
space for some devices, by providing multiple stage-1 page directories. In
addition to the Stream ID (SID), that identifies a device, we can now have
For platform devices that support SubstreamID (SSID), firmware provides
the number of supported SSID bits. Restrict it to what the SMMU supports
and cache it into master->ssid_bits, which will also be used for PCI
PASID.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by:
Second-level context descriptor tables will be allocated lazily in
arm_smmu_write_ctx_desc(). Help with handling allocation failure by
moving the CD write into arm_smmu_domain_finalise_s1().
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
On Arm systems, some platform devices behind an SMMU may support the PASID
feature, which offers multiple address space. Let the firmware tell us
when a device supports PASID.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
Enable PASID for PCI devices that support it. Since the SSID tables are
allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
arm_smmu_dev_feature_enable() would be too late, since by that time the
main DMA domain has already been attached. Do it in add_device() instead.
Let add_device() clean up after itself. The iommu_bus_init() function
does call remove_device() on error, but other sites (e.g. of_iommu) do
not.
Don't free level-2 stream tables because we'd have to track if we
allocated each of them or if they are used by other endpoints. It's not
worth the
When adding SSID support to the SMMUv3 driver, we'll need to manipulate
leaf pasid tables and context descriptors. Extract the context
descriptor structure and introduce a new table structure.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
The SMMU can support up to 20 bits of SSID. Add a second level of page
tables to accommodate this. Devices that support more than 1024 SSIDs now
have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
descriptors (64kB), allocated on demand.
Tested-by: Zhangfei Gao
Reviewed-by:
Add support for Substream ID and PASIDs to the SMMUv3 driver. Since v3
[1], I added review and tested tags where appropriate and applied the
suggested changes, shown in the diff below. Thanks all!
I'm testing using the zip accelerator on the Hisilicon KunPeng920 and
Zhangfei's uacce module [2].
Named component nodes in the IORT tables describe the number of
Substream ID bits (aka. PASID) supported by the device. Propagate this
value to the fwspec structure in order to enable PASID for platform
devices.
Acked-by: Hanjun Guo
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
On Thu, Dec 19, 2019 at 01:47:47PM +0100, Thierry Reding wrote:
> On Thu, Dec 19, 2019 at 09:53:22AM +0800, Lu Baolu wrote:
> > Please tweak the title to
> >
> > "iommu/vt-d: Use generic_iommu_put_resv_regions()"
> >
> > then,
> >
> > Acked-by: Lu Baolu
> >
> > Best regards,
> > baolu
>
>
Hi Christoph,
On 19/12/2019 17.02, Christoph Hellwig wrote:
> Hi Peter,
>
> can you try the patch below (it will need to be split into two):
Thank you!
Unfortunately it does not help:
[0.596208] edma: probe of 270.edma failed with error -5
[0.596626] edma: probe of 2728000.edma
Hi,
On 09/07/2019 17.20, Christoph Hellwig wrote:
> The DMA API requires that 32-bit DMA masks are always supported, but on
> arm LPAE configs they do not currently work when memory is present
> above 4GB. Wire up the swiotlb code like for all other architectures
> to provide the bounce
Hi Peter,
can you try the patch below (it will need to be split into two):
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e822af0d9219..30b9c6786ce3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -221,7 +221,8 @@
On Thu, Dec 19, 2019 at 12:03:36PM +, Will Deacon wrote:
> Hi all,
>
> This is version four of the patches I previously posted here:
>
> v1: https://lore.kernel.org/lkml/20191030145112.19738-1-w...@kernel.org/
> v2: https://lore.kernel.org/lkml/20191108151608.20932-1-w...@kernel.org
>
On Thu, Dec 19, 2019 at 12:03:41PM +, Will Deacon wrote:
> To avoid accidental removal of an active IOMMU driver module, take a
> reference to the driver module in 'iommu_probe_device()' immediately
> prior to invoking the '->add_device()' callback and hold it until the
> after the device has
Hi All,
We still have some issues with PCI cards in our FSL P5020 and P5040
systems since the DMA mapping updates. [1, 2]
We have to limit the RAM to 3500MB for some problematic PCI cards.
(kernel boot argument 'mem=3500M')
The problematic DMA mapping code was added with the PowerPC
The last level system cache can be partitioned to 32 different slices
of which GPU has two slices preallocated. One slice is used for caching GPU
buffers and the other slice is used for caching the GPU SMMU pagetables.
This patch talks to the core system cache driver to acquire the slice handles,
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 8
From: Jordan Crouse
Pass the propposed io_pgtable_cfg to the implementation specific
init_context() function to give the implementation an opportunity to
to modify it before it gets passed to io-pgtable.
Signed-off-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
Some hardware variants contain a system level cache or the last level
cache(llc). This cache is typically a large block which is shared by multiple
clients on the SOC. GPU uses the system cache to cache both the GPU data
buffers(like textures) as well the SMMU pagetables. This helps with
improved
From: Vivek Gautam
Add iommu domain attribute for using system cache aka last level
cache on QCOM SoCs by client drivers like GPU to set right
attributes for caching the hardware pagetables into the system cache.
Signed-off-by: Vivek Gautam
Co-developed-by: Sai Prakash Ranjan
Signed-off-by:
Allow different Adreno targets the ability to pass
specific mmu features to the generic layers. This will
help conditionally configure certain iommu features for
certain Adreno targets.
Also Add a few simple support functions to support a bitmask of
features that a specific MMU implementation
On Thu, Dec 19, 2019 at 09:53:22AM +0800, Lu Baolu wrote:
> Please tweak the title to
>
> "iommu/vt-d: Use generic_iommu_put_resv_regions()"
>
> then,
>
> Acked-by: Lu Baolu
>
> Best regards,
> baolu
Joerg, do you want me to resend with this change or is it more efficient
if you fix up the
On 19/12/2019 12:03, Will Deacon wrote:
Hi all,
This is version four of the patches I previously posted here:
v1: https://lore.kernel.org/lkml/20191030145112.19738-1-w...@kernel.org/
v2: https://lore.kernel.org/lkml/20191108151608.20932-1-w...@kernel.org
v3:
I no longer work for Arm, so update the stale reference to my old email
address.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c
This reverts commit addb672f200f4e99368270da205320b83efe01a0.
Let's get the SMMU driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.c | 32 +++-
1 file changed, 19
'bus_set_iommu()' allows IOMMU drivers to register their ops for a given
bus type. Unfortunately, it then doesn't allow them to be removed, which
is necessary for modular drivers to shutdown cleanly so that they can be
reloaded later on.
Allow 'bus_set_iommu()' to take a NULL 'ops' argument,
When removing the SMMU driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.c | 50
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
since it will likely lead to catastrophic failure for any DMA devices
mastering through the SMMU being unbound. When the driver then attempts
to "handle" the fatal faults, it's very easy to trip over dead data
structures,
By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig| 14 ++-
drivers/iommu/Makefile | 3 ++-
By removing the redundant call to 'pci_request_acs()' we can allow the
ARM SMMUv3 driver to be built as a module.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/arm-smmu-v3.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git
Ensure that we hold a reference to the IOMMU driver module while calling
the '->of_xlate()' callback during early device probing.
Signed-off-by: Will Deacon
---
drivers/iommu/of_iommu.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git
This reverts commit c07b6426df922d21a13a959cf785d46e9c531941.
Let's get the SMMUv3 driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 25 -
1 file changed, 16
To avoid accidental removal of an active IOMMU driver module, take a
reference to the driver module in 'iommu_probe_device()' immediately
prior to invoking the '->add_device()' callback and hold it until the
after the device has been removed by '->remove_device()'.
Suggested-by: Joerg Roedel
When removing the SMMUv3 driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 64
From: Ard Biesheuvel
Add support for SMMU drivers built as modules to the ACPI/IORT device
probing path, by deferring the probe of the master if the SMMU driver is
known to exist but has not been loaded yet. Given that the IORT code
registers a platform device for each SMMU that it discovers, we
To avoid having to export 'pci_request_acs()' to modular IOMMU drivers,
move the call into the 'of_dma_configure()' path in a similar manner to
the way in which ACS is configured when probing via ACPI/IORT.
Signed-off-by: Will Deacon
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1
From: Greg Kroah-Hartman
Commit d355bb209783 ("PCI/ATS: Remove unnecessary EXPORT_SYMBOL_GPL()")
unexported a bunch of symbols from the PCI core since the only external
users were non-modular IOMMU drivers. Although most of those symbols
can remain private for now, 'pci_{enable,disable_ats()' is
Building drivers for ATS-aware IOMMUs as modules requires access to
pci_ats_disabled(). Export it as a GPL symbol to get things working.
Acked-by: Bjorn Helgaas
Signed-off-by: Will Deacon
---
drivers/pci/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pci.c
Building IOMMU drivers as modules requires that the core IOMMU API
symbols are exported as GPL symbols.
Signed-off-by: Will Deacon
---
drivers/iommu/iommu-sysfs.c | 5 +
drivers/iommu/iommu.c | 8
2 files changed, 13 insertions(+)
diff --git a/drivers/iommu/iommu-sysfs.c
Hi all,
This is version four of the patches I previously posted here:
v1: https://lore.kernel.org/lkml/20191030145112.19738-1-w...@kernel.org/
v2: https://lore.kernel.org/lkml/20191108151608.20932-1-w...@kernel.org
v3: https://lore.kernel.org/lkml/20191121114918.2293-1-w...@kernel.org
On 18/12/2019 04:39, Cong Wang wrote:
Both find_iova() and __free_iova() take iova_rbtree_lock,
there is no reason to take and release it twice inside
free_iova().
Fold them into one critical section by calling the unlock
versions instead.
Cc: Joerg Roedel
Cc: John Garry
Signed-off-by: Cong
59 matches
Mail list logo
