From: Aaron Ma
[ Upstream commit bb6bccba390c7d743c1e4427de4ef284c8cc6869 ]
Add a non-NULL check to fix potential NULL pointer dereference
Cleanup code to call function once.
Signed-off-by: Aaron Ma
Fixes: 2bf9a0a12749b ('iommu/amd: Add iommu support for ACPI HID devices')
Signed-off-by: Joerg
From: Aaron Ma
[ Upstream commit bb6bccba390c7d743c1e4427de4ef284c8cc6869 ]
Add a non-NULL check to fix potential NULL pointer dereference
Cleanup code to call function once.
Signed-off-by: Aaron Ma
Fixes: 2bf9a0a12749b ('iommu/amd: Add iommu support for ACPI HID devices')
Signed-off-by: Joerg
From: Aaron Ma
[ Upstream commit bb6bccba390c7d743c1e4427de4ef284c8cc6869 ]
Add a non-NULL check to fix potential NULL pointer dereference
Cleanup code to call function once.
Signed-off-by: Aaron Ma
Fixes: 2bf9a0a12749b ('iommu/amd: Add iommu support for ACPI HID devices')
Signed-off-by: Joerg
On Thu, 2019-11-21 at 21:55 -0500, Qian Cai wrote:
> When running heavy memory pressure workloads, this 5+ old system is
> throwing endless warnings below because disk IO is too slow to recover
> from swapping. Since the volume from alloc_iova_fast() could be large,
> once it calls printk(), it wil
When running heavy memory pressure workloads, this 5+ old system is
throwing endless warnings below because disk IO is too slow to recover
from swapping. Since the volume from alloc_iova_fast() could be large,
once it calls printk(), it will trigger disk IO (writing to the log
files) and pending so
Merge pasid-based tlb invalidation into iommu->flush.p_iotlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 43 +
drivers/iommu/intel-pasid.c | 18 ++--
drivers/iommu/intel-svm.c | 23 +++-
3 files changed, 48 inse
Intel VT-d 3.0 introduces more caches and interfaces for software to
flush when it runs in the scalable mode. Currently various cache flush
helpers are scattered around. This consolidates them by putting them in
the existing iommu_flush structure.
/* struct iommu_flush - Intel IOMMU cache invalida
Merge pasid cache invalidation into iommu->flush.pc_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 13 +
drivers/iommu/intel-pasid.c | 18 ++
include/linux/intel-iommu.h | 3 +++
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers
Merge pasid-based device tlb invalidation into iommu->flush.p_dev_tlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 41 +
drivers/iommu/intel-svm.c | 33 ++---
2 files changed, 47 insertions(+), 27 deletions(-)
diff
Merge device tlb invalidation into iommu->flush.dev_tlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/dmar.c| 23 ---
drivers/iommu/intel-iommu.c | 31 +--
drivers/iommu/intel-pasid.c | 3 ++-
include/linux/intel-iommu.h | 2 --
4 files
Intel VT-d 3.0 introduces more cache flush interfaces when it
runs in the scalable mode. Currently various cache flush helpers
are scattered around. This consolidates them by putting them in
the existing iommu_flush structure. The name of each cache flush
operation is defined according to the spec
On Thu, 2019-11-21 at 13:26 -0800, Jacob Pan wrote:
> Use combined macros for_each_svm_dev() to simplify SVM device iteration
> and error checking.
[]
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
[]
> +#define for_each_svm_dev(sdev, svm, d) \
> + li
Mostly extracted from nested SVA/SVM series based on review comments of v7.
https://lkml.org/lkml/2019/10/24/852
This series also adds a few important fixes for native use of SVA. Nested
SVA new code will be submitted separately as a smaller set. Based on the
core branch of IOMMU tree staged for v
When setting up first level page tables for sharing with CPU, we need
to ensure IOMMU can support no less than the levels supported by the
CPU.
It is not adequate, as in the current code, to set up 5-level paging
in PASID entry First Level Paging Mode(FLPM) solely based on CPU.
Currently, intel_p
Use combined macros for_each_svm_dev() to simplify SVM device iteration
and error checking.
Suggested-by: Andy Shevchenko
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Acked-by: Lu Baolu
---
drivers/iommu/intel-svm.c | 81 ++-
1 file changed, 38
Add a check during SVM bind to ensure CPU and IOMMU hardware capabilities
are met.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Acked-by: Lu Baolu
---
drivers/iommu/intel-svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
inde
After each setup for PASID entry, related translation caches must be
flushed. We can combine duplicated code into one function which is less
error prone.
Signed-off-by: Jacob Pan
Reviewed-by: Lu Baolu
Reviewed-by: Eric Auger
Acked-by: Lu Baolu
---
drivers/iommu/intel-pasid.c | 48
Make use of generic IOASID code to manage PASID allocation,
free, and lookup. Replace Intel specific code.
Signed-off-by: Jacob Pan
Reviewed-by: Lu Baolu
Reviewed-by: Eric Auger
Acked-by: Lu Baolu
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 13 +++--
drivers/
Page responses should only be sent when last page in group (LPIG) or
private data is present in the page request. This patch avoids sending
invalid descriptors.
Fixes: 5d308fc1ecf53 ("iommu/vt-d: Add 256-bit invalidation descriptor
support")
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Acked
Shared Virtual Memory(SVM) is based on a collective set of hardware
features detected at runtime. There are requirements for matching CPU
and IOMMU capabilities.
The current code checks CPU and IOMMU feature set for SVM support but
the result is never stored nor used. Therefore, SVM can still be u
PASID allocator uses IDR which is exclusive for the end of the
allocation range. There is no need to decrement pasid_max.
Fixes: af39507305fb ("iommu/vt-d: Apply global PASID in SVA")
Reported-by: Eric Auger
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Acked-by: Lu Baolu
---
drivers/iommu
On 21. Nov 2019, at 19:02, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today but my TV
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
> I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
> attached)
>
> We have to wait to Rolands test results with his SCSI PCI card. I tested it
> today but my TV card doesn't work with this patch.
I think w
On Wed, Nov 06, 2019 at 02:09:26PM +, Robin Murphy wrote:
> Hmm, that bus mask looks pretty wacky - are you able to figure out where
> that's coming from?
arch/powerpc/sysdev/fsl_pci.c:pci_dma_dev_setup_swiotlb().
___
iommu mailing list
iommu@lists.
On Thu, Nov 21, 2019 at 05:07:54PM +, Robin Murphy wrote:
> ^^ super-nit only because I can't not see my editor currently highlighting
> the typo: "accessible"
>
> Regardless of that though,
>
> Reviewed-by: Robin Murphy
Applied for real now with that typo fixed and on top of the pulled in
a
On Thu, Nov 21, 2019 at 04:53:48PM +, Will Deacon wrote:
> Please go ahead and pull in our for-next/zone-dma branch if you need it.
> We're not going to rebase it, and I suspect we won't even be queueing
> anything else there at this stage in the game.
Ok. I've pulled it in and will wait with
On 21/11/2019 9:26 am, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is alre
On Thu, Nov 21, 2019 at 05:02:17PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote:
> > Hmm, there's no functional dependency though, is there? AFAICS it's
> > essentially just a context conflict. Is it worth simply dropping (or
> > postponing) the l
On 21/11/2019 7:34 am, Christoph Hellwig wrote:
Robin, does this mean you ACK this series for the powerpc use case?
Yeah, I think we've nailed down sufficient justification now for having
a generalised flag, so at that point it makes every bit of sense to
convert PPC's private equivalent.
R
Am 21.11.19 um 14:33 schrieb Robin Murphy:
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA add
On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote:
> Hmm, there's no functional dependency though, is there? AFAICS it's
> essentially just a context conflict. Is it worth simply dropping (or
> postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
> perhaps even cross-
On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only ho
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a
On Thu, 2019-11-21 at 16:24 +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA mappin
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when sup
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
* 2 : 64 bit addressing when supported by
On Tue, Nov 19, 2019 at 12:49:24PM +0100, Nicolas Saenz Julienne wrote:
> On Tue, 2019-11-19 at 11:18 +, Andrew Murray wrote:
> > On Tue, Nov 12, 2019 at 04:59:19PM +0100, Nicolas Saenz Julienne wrote:
> > > This series aims at providing support for Raspberry Pi 4's PCIe
> > > controller, which
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 b/drivers/iommu/arm-s
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, le
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 +--
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 insertions
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 | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/of_iommu.c
'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, which
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
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 a/drivers/iommu/K
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 ++-
drive
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 b/dr
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 insertio
Hi everyone,
This is version three 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
Changes since v2 include:
* Tested successfully on real hardware (!)
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 insertio
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 b/drivers/pci/p
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
Sign
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
Wi
On Thu, 2019-11-21 at 08:31 +0100, Christoph Hellwig wrote:
> On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote:
> > TBH I can't see it being a massive problem even if the DMA patch, driver
> > and DTS patch went entirely separately via the respective DMA, PCI, and
> > arm-soc trees in
56 matches
Mail list logo
