On 2022-07-08 18:08, Ben Dooks wrote:
If the io_tlb_default_mem is used by a device that then gets used
by the swiotlb code, the spinlock warning is triggered causing a
lot of stack-trace.
Hang on, how have we got as far as trying to allocate out of an
uninitialised SWIOTLB at all? That seems
of these registers are not
accessible in non-secure world such as from kernel and requires SMC
calls to read them in the secure world. So, add this debug support
to dump implementation defined registers for TLB sync timeout issues.
FWIW,
Acked-by: Robin Murphy
Signed-off-by: Sai Prakash Ranjan
On 2022-05-26 05:14, Sai Prakash Ranjan wrote:
TLB sync timeouts can be due to various reasons such as TBU power down
or pending TCU/TBU invalidation/sync and so on. Debugging these often
require dumping of some implementation defined registers to know the
status of TBU/TCU operations and some
On 2022-07-06 09:38, Alexey Kardashevskiy wrote:
On 28/04/2022 23:18, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary. This also
leaves the custom initcall effectively doing nothing but register
the driver, which no longer needs to happen early either, so convert
On 2022-07-05 07:22, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of
On 2022-07-05 05:51, Baolu Lu wrote:
Hi Robin,
On 2022/4/30 02:06, Robin Murphy wrote:
On 29/04/2022 9:50 am, Robin Murphy wrote:
On 2022-04-29 07:57, Baolu Lu wrote:
Hi Robin,
On 2022/4/28 21:18, Robin Murphy wrote:
Move the bus setup to iommu_device_register(). This should allow
On 2022-06-15 17:12, Logan Gunthorpe wrote:
Make use of the third free LSB in scatterlist's page_link on 64bit systems.
The extra bit will be used by dma_[un]map_sg_p2pdma() to determine when a
given SGL segments dma_address points to a PCI bus address.
dma_unmap_sg_p2pdma() will need to
On 2022-06-11 21:48, Aaron Tomlin wrote:
This patch will attempt to describe the region type in the event
that a given RMRR entry is not within a reserved region.
Hmm, is this useful information for the user? You'd hope the firmware
vendor knows the memory map already, but either way, is it
On 01/07/2022 5:43 pm, Nicolin Chen wrote:
On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 2ed3594f384e..072cac5ab5a4 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers
On 2022-07-01 12:33, John Garry wrote:
On 01/07/2022 04:56, Feng Tang wrote:
inclination.
ok, what you are saying sounds reasonable. I just remember that when we
analyzed the longterm aging issue that we concluded that the FQ size
and its
relation to the magazine size was a factor and this
On 2022-06-30 21:36, Nicolin Chen wrote:
Cases like VFIO wish to attach a device to an existing domain that was
not allocated specifically from the device. This raises a condition
where the IOMMU driver can fail the domain attach because the domain and
device are incompatible with each other.
On 2022-07-01 08:19, Baolu Lu wrote:
On 2022/6/29 21:03, Robin Murphy wrote:
On 2019-06-12 01:28, Lu Baolu wrote:
The drhd and device scope list should be iterated with the
iommu global lock held. Otherwise, a suspicious RCU usage
message will be displayed.
[ 3.695886
On 2022-06-30 10:29, yf.w...@mediatek.com wrote:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add
the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2
pgtable support at most 35bit PA.
FWIW,
Reviewed-by: Robin Murphy
Signed-off
up to bit35.
This looks about as clean as it's likely to get now, thanks for persevering.
Reviewed-by: Robin Murphy
Signed-off-by: Ning Li
Signed-off-by: Yunfei Wang
---
drivers/iommu/io-pgtable-arm-v7s.c | 75 ++
include/linux/io-pgtable.h | 15
On 2022-06-29 23:41, Logan Gunthorpe wrote:
On 2022-06-29 13:15, Robin Murphy wrote:
On 2022-06-29 16:57, Logan Gunthorpe wrote:
On 2022-06-29 06:07, Robin Murphy wrote:
On 2022-06-15 17:12, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
On 2022-06-30 10:37, John Garry wrote:
On 30/06/2022 10:02, Robin Murphy wrote:
On 2022-06-30 08:33, Feng Tang wrote:
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc
, though.
Acked-by: Robin Murphy
#define MAX_GLOBAL_MAGS 32/* magazines per bin */
struct iova_magazine {
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2022-06-29 20:47, Nicolin Chen wrote:
On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
It's not used in VFIO context. "return 0" just satisfy the iommu
framework to go ahead. and yes, here we only allow the shared
On 2022-06-29 16:57, Logan Gunthorpe wrote:
On 2022-06-29 06:07, Robin Murphy wrote:
On 2022-06-15 17:12, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the appropriate
On 2022-06-29 16:39, Logan Gunthorpe wrote:
On 2022-06-29 03:05, Robin Murphy wrote:
On 2022-06-15 17:12, Logan Gunthorpe wrote:
Make use of the third free LSB in scatterlist's page_link on 64bit
systems.
The extra bit will be used by dma_[un]map_sg_p2pdma() to determine when a
given SGL
On 2019-06-12 01:28, Lu Baolu wrote:
The drhd and device scope list should be iterated with the
iommu global lock held. Otherwise, a suspicious RCU usage
message will be displayed.
[3.695886] =
[3.695917] WARNING: suspicious RCU usage
[3.695950]
On 2022-06-15 17:12, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the appropriate bus address to the segment. The IOVA is not
created if the scatterlist only consists of
On 2022-06-15 17:12, Logan Gunthorpe wrote:
Make use of the third free LSB in scatterlist's page_link on 64bit systems.
The extra bit will be used by dma_[un]map_sg_p2pdma() to determine when a
given SGL segments dma_address points to a PCI bus address.
dma_unmap_sg_p2pdma() will need to
On 2022-06-27 16:25, John Garry wrote:
Streaming DMA mapping involving an IOMMU may be much slower for larger
total mapping size. This is because every IOMMU DMA mapping requires an
IOVA to be allocated and freed. IOVA sizes above a certain limit are not
cached, which can have a big impact on
must always be newly allocated, which may be quite slow.
Acked-by: Robin Murphy
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff
On 2022-06-27 20:21, Alex Williamson wrote:
On Fri, 24 Jun 2022 18:51:44 +0100
Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully added to a group
must be on a bus supported by that IOMMU driver
On 2022-06-21 08:18, Janne Grunau wrote:
From: Sven Peter
The DARTs present in the M1 Pro/Max/Ultra SoC use a diffent PTE format.
They support a 42bit physical address space by shifting the paddr and
extending its mask inside the PTE.
They also come with mandatory sub-page protection now which
utive pages.
+*/
+ if (data->start_level == 0 && data->pgd_bits > 2)
+ goto out_free_data;
+ if (data->start_level > 0)
+ data->pgd_bits = 0;
+ data->start_level = 1;
+ cfg->apple_dart_cfg.n_ttbrs = 1 << da
ked-by: Robin Murphy
Thanks,
Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2022-06-24 14:16, Jason Gunthorpe wrote:
On Wed, Jun 22, 2022 at 08:54:45AM +0100, Robin Murphy wrote:
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
syst
Use the new interface to check the capabilities for our device
specifically.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 61e71c1154be..4c06b571eaba
the same capability which was expected to be consistent across an
entire bus! - so there's no need for any complicated validation.
Signed-off-by: Robin Murphy
---
v3: Complete rewrite yet again, and finally it doesn't feel like we're
stretching any abstraction boundaries the wrong way
On 2022-06-24 15:28, Alex Williamson wrote:
On Fri, 24 Jun 2022 11:18:36 -0300
Jason Gunthorpe wrote:
On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
On Thu, 23 Jun 2022 22:50:30 -0300
Jason Gunthorpe wrote:
On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson
On 2022-06-24 14:28, Joerg Roedel wrote:
On Thu, Jun 23, 2022 at 12:41:00PM +0100, Robin Murphy wrote:
On 2022-06-23 12:33, Joerg Roedel wrote:
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
Thanks for your bravery!
It already starts, with that patch I am getting
On 2022-06-22 23:17, Alex Williamson wrote:
On Wed, 22 Jun 2022 13:04:11 +0100
Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
s/be //
Oops.
must be on a bus supported
On 2022-06-23 12:33, Joerg Roedel wrote:
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
Thanks for your bravery!
It already starts, with that patch I am getting:
xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000f address=0xff00ffefe000 flags
On 2022-06-23 02:54, Yong Wu wrote:
On Thu, 2022-06-16 at 11:31 +0100, Robin Murphy wrote:
On 2022-06-16 11:08, Yong Wu wrote:
On Thu, 2022-06-16 at 09:59 +0100, Robin Murphy wrote:
On 2022-06-16 06:42, Yong Wu wrote:
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if
the
i+1
larb
On 2022-06-23 09:03, Joerg Roedel wrote:
On Fri, Jun 03, 2022 at 04:51:03PM +0530, Vasant Hegde wrote:
Fix below sparse warning:
CHECK drivers/iommu/amd/iommu.c
drivers/iommu/amd/iommu.c:73:24: warning: symbol 'amd_iommu_ops' was not
declared. Should it be static?
Also we are going to
: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
helpers")
Signed-off-by: Dexuan Cui
see:
commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
dma-mapping-5.19-2022-05-25)
Author: Robin Murphy
Date: Fri May 20 18:10:13 2022 +0100
dma-direct: don't over-decrypt memory
On 2022-06-22 13:46, Joerg Roedel wrote:
Please re-send with
Robin Murphy
in Cc.
Apologies, I did spot this before, I've just been tied up with other
things and dropping everything non-critical on the floor, so didn't get
round to replying before it slipped my mind again
On 2022-06-22 13:59, Joerg Roedel wrote:
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote:
firmware bindings by now. Let's be brave and default it to off in the
I don't have an overall good feeling about this, but as you said, let's
be brave. This is applied now to the core branch
Use the new interface to check the capabilities for our device
specifically.
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
. Holding the
vfio_device for as long as we need here also neatly solves this.
Signed-off-by: Robin Murphy
---
After sleeping on it, I decided to type up the helper function approach
to see how it looked in practice, and in doing so realised that with one
more tweak it could also subsume the locking
On 2022-06-21 20:57, Sam Protsenko wrote:
Hi Marek,
On Fri, 21 Jan 2022 at 14:31, Marek Szyprowski wrote:
[snip]
Well, for starting point the existing exynos-iommu driver is really
enough. I've played a bit with newer Exyos SoCs some time ago. If I
remember right, if you limit the iommu
sted
not to flood their own logs :/
Either way,
Reviewed-by: Robin Murphy
+ return NULL;
+ }
+
domain = protection_domain_alloc(type);
if (!domain)
return NULL;
___
iommu mailing list
hanks! FWIW, with those nits picked one
way or another:
Reviewed-by: Robin Murphy
Cheers,
Robin.
+
#endif /* _ASM_X86_AMD_IOMMU_H */
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
systems. However, at this moment only one iommu driver is possible. So
remove it.
It's true on a physical platform.
On 2022-06-22 02:36, Baolu Lu wrote:
On 2022/6/21 23:14, Robin Murphy wrote:
Since .release_device is now called through per-device ops, any call
which gets as far as a driver definitely*is* for that driver, for a
device which has successfully passed .probe_device, so all the checks
On 2022-06-10 01:03, Jason Gunthorpe via iommu wrote:
On Wed, Jun 08, 2022 at 03:25:49PM +0100, Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
must be on a bus supported
freeing fwspecs which are now managed by core code.
Signed-off-by: Robin Murphy
---
drivers/iommu/apple-dart.c | 3 ---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 +---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 14 +++---
drivers/iommu/arm/arm-smmu
The ->probe_finalize hook only runs after ->probe_device succeeds,
so we can move that over to the new dev_iommu_ops() as well.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers
Many drivers do nothing meaningful for .release_device, and it's neatly
abstracted to just two callsites in the core code, so let's make it
optional to implement.
Signed-off-by: Robin Murphy
---
drivers/iommu/fsl_pamu_domain.c | 5 -
drivers/iommu/iommu.c | 6 --
drivers/iommu
Hi all,
Here are a few more thematically-related patches from my develompent
stack that don't depend on the rest, so may as well get some exposure
sooner rather than later.
Thanks,
Robin.
Robin Murphy (3):
iommu: Use dev_iommu_ops() for probe_finalize
iommu: Make .release_device optional
On 2022-06-17 03:53, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Friday, June 17, 2022 6:41 AM
...
- if (resv_msi) {
+ if (resv_msi && !domain->msi_cookie) {
ret = iommu_get_msi_cookie(domain->domain,
resv_msi_base);
if (ret && ret != -ENODEV)
On 2022-06-17 17:17, Frank Wunderlich wrote:
Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig :
On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote:
Put simply, if you want to call dma_map_single() on a buffer, then that
buffer needs to be allocated with kmalloc
t.
For now, though, I agree with the simple change that's clear and easy to
reason about:
Reviewed-by: Robin Murphy
Thanks,
Robin.
Cc: Maciej W. Rozycki
Cc: Matt Wang
Cc: Khalid Aziz
Signed-off-by: Arnd Bergmann
---
drivers/scsi/BusLogic.c | 27 ---
drivers/
On 2022-06-16 11:08, Yong Wu wrote:
On Thu, 2022-06-16 at 09:59 +0100, Robin Murphy wrote:
On 2022-06-16 06:42, Yong Wu wrote:
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the
i+1
larb is parsed fail(return -EINVAL), we should of_node_put for the
0..i
larbs. In the fail path
On 2022-06-16 06:42, Yong Wu wrote:
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the i+1
larb is parsed fail(return -EINVAL), we should of_node_put for the 0..i
larbs. In the fail path, one of_node_put matches with of_parse_phandle in
it.
Fixes: d2e9a1102cfc ("iommu/mediatek:
On 2022-06-15 17:12, yf.wang--- via iommu wrote:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add
the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2
pgtable support at most 35bit PA.
I'm not sure how this works in practice, given
On 2022-06-15 17:12, yf.wang--- via iommu wrote:
From: Yunfei Wang
Rename MTK_IOMMU_TLB_ADDR to MTK_IOMMU_ADDR, and update MTK_IOMMU_ADDR
definition for better generality.
Signed-off-by: Ning Li
Signed-off-by: Yunfei Wang
---
drivers/iommu/mtk_iommu.c | 8
1 file changed, 4
On 2022-06-15 17:12, yf.w...@mediatek.com wrote:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.
Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support
On 2022-06-15 13:11, Frank Wunderlich wrote:
Hi,
i have upported a wifi-driver (mt6625l for armhf) for some time and fall now
(at least 5.18) in the
"rejecting DMA map of vmalloc memory" error [1].
maybe anybody here can guide me on how to nail it down and maybe fix it.
as far as i have
-by: Robin Murphy
I'm seeing a regression that I've bisected to this commit on a Firefly
RK3288 board. The display driver fails to probe properly because
__iommu_attach_group() returns -EBUSY. This causes long hangs and splats
as the display flips timeout.
The call stack to __iommu_attach_group
On 2022-06-13 15:38, Suthikulpanit, Suravee wrote:
Robin,
On 6/13/2022 4:31 PM, Robin Murphy wrote:
On 2022-06-13 02:25, Suravee Suthikulpanit wrote:
When user requests to change IOMMU domain to a new type, IOMMU generic
layer checks the requested type against the default domain type returned
On 2022-06-13 02:25, Suravee Suthikulpanit wrote:
When user requests to change IOMMU domain to a new type, IOMMU generic
layer checks the requested type against the default domain type returned
by vendor-specific IOMMU driver.
However, there is only one default domain type, and current
compatibility.
Signed-off-by: Robin Murphy
---
v2: Tweak wording to clarify that it's not really an optimisation in
general, remove "default X86".
drivers/iommu/Kconfig | 26 ++
drivers/iommu/dma-iommu.c | 2 +-
2 files changed, 27 insertions(+),
On 2022-06-09 13:49, Jason Gunthorpe wrote:
On Thu, Jun 09, 2022 at 03:08:10PM +0800, Lu Baolu wrote:
The IOMMU page tables are updated using iommu_map/unmap() interfaces.
Currently, there is no mandatory requirement for drivers to use locks
to ensure concurrent updates to page tables, because
Use the new interface to check the capabilities for our device
specifically.
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
to block any relevant
device's VFIO driver from unregistering, and thus block unbinding and
any further stages of removal for the duration of the attach operation.
Signed-off-by: Robin Murphy
---
With vfio_group_viable() now gone and no longer taking the vfio_group
device_lock inside
On 2022-06-08 11:27, AngeloGioacchino Del Regno wrote:
Il 06/06/22 00:06, Marijn Suijten ha scritto:
On 2022-05-31 16:55:59, Will Deacon wrote:
On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
From: AngeloGioacchino Del Regno
As also stated in the arm-smmu driver, we must
On 2022-06-06 17:51, Nicolin Chen wrote:
Hi Robin,
On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote:
On 2022-06-06 07:19, Nicolin Chen wrote:
The core code should not call an iommu driver op with a struct device
parameter unless it knows that the dev_iommu_priv_get
On 2022-06-06 07:19, Nicolin Chen wrote:
The core code should not call an iommu driver op with a struct device
parameter unless it knows that the dev_iommu_priv_get() for that struct
device was setup by the same driver. Otherwise in a mixed driver system
the iommu_priv could be casted to the
On 2022-06-02 16:58, Marek Szyprowski wrote:
Hi Robin,
On 23.05.2022 19:30, Robin Murphy wrote:
On 2022-05-11 13:15, Ajay Kumar wrote:
From: Marek Szyprowski
Zero is a valid DMA and IOVA address on many architectures, so adjust
the
IOVA management code to properly handle it. A new value
On 2022-05-31 23:10, Tony Battersby wrote:
On 5/31/22 17:54, Keith Busch wrote:
On Tue, May 31, 2022 at 02:23:44PM -0400, Tony Battersby wrote:
dma_pool_free() scales poorly when the pool contains many pages because
pool_find_page() does a linear scan of all allocated pages. Improve its
On 2022-05-31 22:51, Rob Clark wrote:
From: Rob Clark
Ratelimit the error msg to avoid flooding the console.
Signed-off-by: Rob Clark
---
kernel/dma/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index
On 2022-05-31 20:52, Tony Battersby wrote:
On 5/31/22 15:48, Robin Murphy wrote:
On 2022-05-31 19:17, Tony Battersby wrote:
pool->name, blocks,
-(size_t) pages *
-(pool->allocation / pool
On 2022-05-31 19:51, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:
And we expect the iommu driver to be unable to free page table levels
that have IOVA boundaries in them?
I'm not entirely sure what you mean there, but in general an unmap request
On 2022-05-31 19:17, Tony Battersby wrote:
The "total number of blocks in pool" debug statistic currently does not
take the boundary value into account, so it diverges from the "total
number of blocks in use" statistic when a boundary is in effect. Add a
calculation for the number of blocks per
On 2022-05-31 19:22, Tony Battersby wrote:
Remove a small amount of code duplication between dma_pool_destroy() and
pool_free_page() in preparation for adding more code without having to
duplicate it. No functional changes.
Signed-off-by: Tony Battersby
---
mm/dmapool.c | 34
oth insufficient and causing bloat.
Remove them.
Furthermore, dma_pool_create() already dereferences the dev argument
unconditionally, so there's no way we could possibly get as far as these
checks even if a caller did ever pass NULL.
Reviewed-by: Robin Murphy
Signed-off-by: Tony Battersby
---
On 2022-05-31 17:21, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 05:01:46PM +0100, Robin Murphy wrote:
The DMA API doesn't need locking, partly since it can trust itself not to do
stupid things, and mostly because it's DMA API performance that's
fundamentally incompatible with serialisation
On 2022-05-31 16:59, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
+ break;
+ pgtable_walk_level(m, phys_to_virt(phys_addr),
Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
gets you a valid struct page
On 2022-05-31 16:55, Will Deacon wrote:
On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
From: AngeloGioacchino Del Regno
As also stated in the arm-smmu driver, we must write the TCR before
writing the TTBRs, since the TCR determines the access behavior of
some fields.
Where
On 2022-05-31 16:13, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 04:01:04PM +0100, Robin Murphy wrote:
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
For case 2, it is a bit weird. I tried to add a rwsem lock to make the
iommu_unmap() and
On 2022-05-31 04:02, Baolu Lu wrote:
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
From 1e87b5df40c6ce9414cdd03988c3b52bfb17af5f Mon Sep 17 00:00:00 2001
From: Lu Baolu
Date: Sun, 29 May 2022 10:18:56 +0800
Subject: [PATCH 1/1]
On 2022-05-25 07:20, Baolu Lu wrote:
Hi Robin,
On 2022/5/24 22:36, Robin Murphy wrote:
On 2022-05-19 08:20, Lu Baolu wrote:
[...]
diff --git a/drivers/iommu/iommu-sva-lib.c
b/drivers/iommu/iommu-sva-lib.c
index 106506143896..210c376f6043 100644
--- a/drivers/iommu/iommu-sva-lib.c
+++ b
On 2022-05-19 08:20, Lu Baolu wrote:
[...]
diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c
index 106506143896..210c376f6043 100644
--- a/drivers/iommu/iommu-sva-lib.c
+++ b/drivers/iommu/iommu-sva-lib.c
@@ -69,3 +69,51 @@ struct mm_struct *iommu_sva_find(ioasid_t
On 2022-05-11 13:15, Ajay Kumar wrote:
From: Marek Szyprowski
Zero is a valid DMA and IOVA address on many architectures, so adjust the
IOVA management code to properly handle it. A new value IOVA_BAD_ADDR
(~0UL) is introduced as a generic value for the error case. Adjust all
callers of the
On 2022-05-23 12:54, Johan Hovold wrote:
On Mon, May 23, 2022 at 11:11:45AM +, cgel@gmail.com wrote:
From: Minghao Chi
The OF node should be put before returning error in ipmmu_init(),
otherwise node's refcount will be leaked.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
On 2022-05-23 11:15, Mark-PK Tsai wrote:
Sigh. In theory drivers should never declare coherent memory like
this, and there has been some work to fix remoteproc in that regard.
But I guess until that is merged we'll need somthing like this fix.
Hi,
Thanks for your comment.
As I didn't see
of the next adjacent
vmalloc area, only averted by no architecture actually supporting both
configs at once. Don't ask how I found that one out...
CC: sta...@vger.kernel.org
Fixes: c10f07aa27da ("dma/direct: Handle force decryption for DMA coherent
buffers in common code")
Signed-off-by: Ro
On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
This control causes the ARM SMMU drivers to choose a stage 2
implementation for the IO pagetable (vs the stage 1 usual default),
however this choice has no visible impact to the VFIO user.
Oh, I should have read more carefully... this isn't
On 2022-05-20 09:58, Joerg Roedel wrote:
On Fri, May 20, 2022 at 09:54:51AM +0100, Robin Murphy wrote:
The .def_domain type op already allows drivers to do exactly this sort of
override. You could also conditionally reject IOMMU_DOMAIN_PASSTHROUGH in
.domain_alloc for good measure, provided
On 2022-05-20 09:09, Joerg Roedel wrote:
Hi Suravee,
On Mon, May 16, 2022 at 07:27:51PM +0700, Suravee Suthikulpanit wrote:
Due to the new restriction (please see the IOMMU spec Rev 3.06-PUB - Apr 2021
https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf) where the use of
DTE[Mode]=0 is
adding it to iommu-dma, but those really should now be fixed with proper
firmware bindings, and other arm64 users really need it out of the way,
so let's just leave it default-on for x86.
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 24
drivers/iommu/dma
On 2022-05-18 14:12, Christoph Hellwig wrote:
On Tue, May 17, 2022 at 11:40:52AM +0100, Robin Murphy wrote:
Indeed, sorry but NAK for this being nonsense. As I've said at least once
before, if the unnecessary SAC address allocation attempt slows down your
workload, make it not do
On 2022-05-18 09:29, AngeloGioacchino Del Regno wrote:
Il 17/05/22 16:12, Robin Murphy ha scritto:
On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting
On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to
On 2022-05-17 03:37, Baolu Lu wrote:
Hi Jason,
On 2022/5/16 21:57, Jason Gunthorpe wrote:
On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
On 2022-05-16 02:57, Lu Baolu wrote:
Each IOMMU driver must provide a blocking domain ops. If the hardware
supports detaching domain from
1 - 100 of 3413 matches
Mail list logo
