On 2021-11-11 06:50, Christoph Hellwig wrote:
Hi all,
Linus complained about the complex flow in dma_direct_alloc, so this
tries to simplify it a bit, and while I was at it I also made sure that
unencrypted pages never leak back into the page allocator.
Before I forget, I've had a quick skim o
On 2021-11-16 09:06, Yicong Yang via iommu wrote:
[...]
+/*
+ * Get RMR address if provided by the firmware.
+ * Return 0 if the IOMMU doesn't present or the policy of the
+ * IOMMU domain is passthrough or we get a usable RMR region.
+ * Otherwise a negative value is returned.
+ */
+static int h
On 2021-11-15 19:22, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
On 2021-11-15 16:17, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
If userspace has control of device A and can cause A to issue DMA to
arbitary
On 2021-11-15 18:19, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 05:54:42PM +, Robin Murphy wrote:
s/PIO/MMIO, but yes basically. And not just data trasnfer but
userspace can interfere with the device state as well.
Sure, but unexpected changes in device state could happen for any
On 2021-11-15 15:56, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 03:37:18PM +, Robin Murphy wrote:
IOMMUs, and possibly even fewer of them support VFIO, so I'm in full
agreement with Greg and Christoph that this absolutely warrants being scoped
per-bus. I mean, we lite
On 2021-11-15 16:17, Jason Gunthorpe wrote:
On Mon, Nov 15, 2021 at 03:14:49PM +, Robin Murphy wrote:
If userspace has control of device A and can cause A to issue DMA to
arbitary DMA addresses then there are certain PCI topologies where A
can now issue peer to peer DMA and manipulate the
On 2021-11-15 13:24, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 05:19:02AM -0800, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:43AM +0800, Lu Baolu wrote:
@@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto do
On 2021-11-15 13:31, Jason Gunthorpe via iommu wrote:
On Mon, Nov 15, 2021 at 05:21:26AM -0800, Christoph Hellwig wrote:
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
pci_stub allows the admin to block driver binding on a device and make
it permanently shared with userspace. Since p
bandwidth needs.
In addition to adding support for the new Tegra234 compatible string,
this also adds a missing description for the nvidia,memory-controller
property to the ARM SMMU device tree binding.
Besides a nitpick about the inconsistent enum ordering in patch #2,
Acked-by: Robin Murphy
On 2021-11-10 09:35, Tvrtko Ursulin wrote:
On 10/11/2021 07:25, Lu Baolu wrote:
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wr
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wr
On 2021-11-10 09:35, Tvrtko Ursulin wrote:
On 10/11/2021 07:25, Lu Baolu wrote:
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that
On 2021-11-06 10:42, Paul Menzel wrote:
Dear Bjorn,
Thank you for your quick reply.
Am 05.11.21 um 19:53 schrieb Bjorn Helgaas:
On Fri, Nov 05, 2021 at 12:56:09PM +0100, Paul Menzel wrote:
On a PowerEdge T440/021KCD, BIOS 2.11.2 04/22/2021, Linux 5.10.70 takes
almost five seconds to initi
On 2021-11-09 14:25, Christoph Hellwig wrote:
On Thu, Nov 04, 2021 at 12:36:16PM +, Robin Murphy wrote:
- *dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
- /* return the page pointer as the opaque cookie */
- return page
On 2021-11-09 14:10, Christoph Hellwig wrote:
On Thu, Nov 04, 2021 at 12:35:41PM +, Robin Murphy wrote:
On 2021-10-21 10:06, Christoph Hellwig wrote:
When dma_set_decrypted fails for the remapping case in dma_direct_alloc
we also need to unmap the pages before freeing them.
Signed-off-by
On 2021-10-21 10:06, Christoph Hellwig wrote:
Add a helper to check if a potentially blocking operation should
dip into the atomic pools.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 18 --
1 file changed, 12 insertions(+), 6
On 2021-10-21 10:06, Christoph Hellwig wrote:
Add a new helper to deal with the swiotlb case. This keeps the code
nicely boundled and removes the not required call to
dma_direct_optimal_gfp_mask for the swiotlb case.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel
On 2021-10-21 10:06, Christoph Hellwig wrote:
swiotlb_alloc and swiotlb_free are properly stubbed out if
CONFIG_DMA_RESTRICTED_POOL is not set, so skip the extra checks.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 6 ++
1 file changed, 2
On 2021-10-21 10:06, Christoph Hellwig wrote:
Instead of blindly running into a blocking operation for a non-blocking gfp,
return NULL and spew an error. Note that Kconfig prevents this for all
currently relevant platforms, and this is just a debug check.
Reviewed-by: Robin Murphy
Signed
On 2021-10-21 10:06, Christoph Hellwig wrote:
Split the code for DMA_ATTR_NO_KERNEL_MAPPING allocations into a separate
helper to make dma_direct_alloc a little more readable.
Signed-off-by: Christoph Hellwig
Acked-by: David Rientjes
---
kernel/dma/direct.c | 31 -
On 2021-10-21 10:06, Christoph Hellwig wrote:
Add a big central !dev_is_dma_coherent(dev) block to deal with as much
as of the uncached allocation schemes and document the schemes a bit
better.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 58 -
On 2021-10-21 10:06, Christoph Hellwig wrote:
Add a local variable to track if we want to remap the returned address
using vmap and use that to simplify the code flow.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 47 +++--
1 file changed,
On 2021-10-21 10:06, Christoph Hellwig wrote:
We must never unencryped memory go back into the general page pool.
So if we fail to set it back to encrypted when freeing DMA memory, leak
the memory insted and warn the user.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 18
On 2021-10-21 10:06, Christoph Hellwig wrote:
When dma_set_decrypted fails for the remapping case in dma_direct_alloc
we also need to unmap the pages before freeing them.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
On 2021-10-21 10:06, Christoph Hellwig wrote:
Factor out helpers the make dealing with memory encryption a little less
cumbersome.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 56 -
1 file changed, 25
think the only way to absolutely guarantee that is to exclude it from
the kernel's memory map in the first place, e.g. as a DT reserved-memory
region with the "no-map" property.
Robin.
Signed-off-by: Walter Wu
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
On 27/10/2021 5:45 pm, Paul Menzel wrote:
Dear Robin,
On 25.10.21 18:01, Robin Murphy wrote:
On 2021-10-25 12:23, Christian König wrote:
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like
-1 or
On 27/10/2021 5:45 pm, Paul Menzel wrote:
Dear Robin,
On 25.10.21 18:01, Robin Murphy wrote:
On 2021-10-25 12:23, Christian König wrote:
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like
-1 or
On 2021-10-25 12:23, Christian König wrote:
Hi Paul,
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like -1
or similar.
FWIW those look like believable DMA addresses to me, assuming that the
DMA mapping
On 2021-10-25 12:23, Christian König wrote:
Hi Paul,
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like -1
or similar.
FWIW those look like believable DMA addresses to me, assuming that the
DMA mapping
On 2021-10-22 09:06, Marc Zyngier wrote:
On Fri, 22 Oct 2021 03:52:38 +0100,
Lu Baolu wrote:
On 10/21/21 4:10 PM, Marc Zyngier wrote:
On Thu, 21 Oct 2021 03:22:30 +0100,
Lu Baolu wrote:
On 10/20/21 10:22 PM, Marc Zyngier wrote:
On Wed, 20 Oct 2021 06:21:44 +0100,
Lu Baolu wrote:
On 202
On 2021-09-28 23:22, Gustavo A. R. Silva wrote:
Use 2-factor argument form kvcalloc() instead of kvzalloc().
If we have a thing for that now, then sure, why not. FWIW this can't
ever overflow due to where "count" comes from, but it has no reason to
be special.
Acked-b
On 2021-10-15 07:36, meng...@windriver.com wrote:
From: Meng Li
When enable debug kernel configs,there will be calltrace as below:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id+0x20/0x30
CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10
On 2021-10-14 12:52, John Garry wrote:
On 14/10/2021 12:20, Matthew Wilcox wrote:
I'm going to keep pinging this patch weekly.
On Thu, Oct 07, 2021 at 07:17:02PM +0100, Matthew Wilcox wrote:
ping?
Robin, Were you checking this? You mentioned "I got
side-tracked trying to make io-pgtable use
On 2021-10-13 19:11, Georgi Djakov wrote:
IOVAs are aligned to the smallest PAGE_SIZE order, where the requested
IOVA can fit. But this might not work for all use-cases. It can cause
IOVA fragmentation in some multimedia and 8K video use-cases that may
require larger buffers to be allocated and m
Hi Daniel,
On 2021-10-13 18:08, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 10:36:54AM -0400, Alyssa Rosenzweig wrote:
From: Robin Murphy
drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc()
will end up calling remap_pfn_range() (which happens to set the relevant
vma flag
On 2021-10-09 08:07, Jon Nettleton wrote:
On Fri, Oct 8, 2021 at 3:10 PM Robin Murphy wrote:
On 2021-08-05 09:07, Shameer Kolothum wrote:
Get ACPI IORT RMR regions associated with a dev reserved
so that there is a unity mapping for them in SMMU.
This feels like most of it belongs in the
On 2021-10-09 08:06, Jon Nettleton wrote:
[...]
+ if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
+ type = IOMMU_RESV_DIRECT_RELAXABLE;
+ /*
+ * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is
+ * normal
On 2021-10-11 06:47, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Jon Nettleton [mailto:j...@solid-run.com]
Sent: 09 October 2021 07:58
To: Robin Murphy
Cc: Shameerali Kolothum Thodi ;
linux-arm-kernel ; ACPI Devel Maling
List ; Linux IOMMU
; Linuxarm ;
Steven Price
On 2021-08-05 09:07, Shameer Kolothum wrote:
Get ACPI IORT RMR regions associated with a dev reserved
so that there is a unity mapping for them in SMMU.
This feels like most of it belongs in the IORT code rather than
iommu-dma (which should save the temporary list copy as well).
Robin.
Sig
On 2021-08-05 09:07, Shameer Kolothum wrote:
Reserved Memory Regions(RMR) associated with an IOMMU can be
described through ACPI IORT tables in systems with devices
that require a unity mapping or bypass for those
regions.
Introduce a generic interface so that IOMMU drivers can retrieve
and set
On 2021-08-05 09:07, Shameer Kolothum wrote:
Add support for parsing RMR node information from ACPI.
Find the associated streamid and smmu node info from the
RMR node and populate a linked list with RMR memory
descriptors.
Signed-off-by: Shameer Kolothum
---
drivers/acpi/arm64/iort.c | 134 +
On 2021-08-05 09:07, Shameer Kolothum wrote:
A union is introduced to struct iommu_resv_region to hold
any firmware specific data. This is in preparation to add
support for IORT RMR reserve regions and the union now holds
the RMR specific information.
Signed-off-by: Shameer Kolothum
---
inclu
On 2021-10-06 14:10, Gerald Schaefer wrote:
On Fri, 1 Oct 2021 14:52:56 +0200
Gerald Schaefer wrote:
On Thu, 30 Sep 2021 15:37:33 +0200
Karsten Graul wrote:
On 14/09/2021 17:45, Ioana Ciornei wrote:
On Wed, Sep 08, 2021 at 10:33:26PM -0500, Jeremy Linton wrote:
+DPAA2, netdev maintainers
On 2021-10-04 12:44, Will Deacon wrote:
On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote:
The IOVA domain structure is a bit overloaded, holding:
- IOVA tree management
- FQ control
- IOVA rcache memories
Indeed only a couple of IOVA users use the rcache, and only dma-iommu.c
uses the
On 2021-10-04 12:44, Will Deacon wrote:
On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote:
The IOVA domain structure is a bit overloaded, holding:
- IOVA tree management
- FQ control
- IOVA rcache memories
Indeed only a couple of IOVA users use the rcache, and only dma-iommu.c
uses the
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a bou
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a bou
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a bou
Now that the dust has settled on converting all the x86 drivers to
iommu-dma, we can punt the Kconfig selection to arch code where it
was always intended to be.
CC: Christoph Hellwig
CC: Marek Szyprowski
CC: x...@kernel.org
CC: linux-i...@vger.kernel.org
Signed-off-by: Robin Murphy
---
arch
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 7 ---
drivers/iommu/iommu.c | 3 +--
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 896bea04c347..26cb95d3830a 100644
--- a
The addition of the DART driver crossed over with moving IOVA cookie
management into core code; clean up the now-unnecessary remnants here.
Acked-by: Sven Peter
Tested-by: Sven Peter
Signed-off-by: Robin Murphy
---
drivers/iommu/apple-dart.c | 2 --
1 file changed, 2 deletions(-)
diff --git
sue
either if you'd prefer to treat it as cleanup for 5.16. Your choice :)
Cheers,
Robin.
Robin Murphy (2):
iommu/dart: Clean up IOVA cookie crumbs
iommu/dma: Unexport IOVA cookie management
drivers/iommu/apple-dart.c | 2 --
drivers/iommu/dma-iommu.c | 7 ---
drivers/iommu/iommu.c
On 2021-09-10 11:09, Guchun Chen wrote:
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
v2: lower check level to WARN_O
On 2021-09-10 11:09, Guchun Chen wrote:
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
v2: lower check level to WARN_O
On 2021-09-10 13:05, Hamza Mahfooz wrote:
For some drivers, that call add_dma_entry() from somewhere down the call
stack.
Nit: strictly, drivers don't call add_dma_entry(). Drivers only call the
DMA API functions, and it is the DMA API internals which take a detour
through dma-debug when desi
n for performance.
These days, reducing the default level of isolation in a way which may
go unnoticed by users who expect otherwise hardly seems worth risking
for the sake of one line of Kconfig, so here's where we are.
Reported-by: Linus Torvalds
Signed-off-by: Robin Murphy
---
drivers/iommu/K
On 2021-09-07 08:41, Kunkun Jiang wrote:
Hi all,
I am working on VFIO DMA dirty pages tracking based on ARM SMMU HTTU,
and have done a lot of testing.In the test, I found a problem that
greatly affects
performance of VFIO DMA dirty pages tracking.
According to the current arm-smmu-v3 driver,
On 2021-08-05 17:03, Lorenzo Pieralisi wrote:
On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
[...]
+static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
+{
+ struct acpi_iort_node *smmu;
+ struct acpi_iort_rmr *rmr;
+ struct acpi_iort
On 2021-09-03 22:44, Joerg Roedel wrote:
On Fri, Sep 03, 2021 at 11:43:31AM -0700, Linus Torvalds wrote:
choice
prompt "IOMMU default domain type"
depends on IOMMU_API
default IOMMU_DEFAULT_DMA_LAZY if AMD_IOMMU || INTEL_IOMMU
default IOMMU_DEFAULT_DMA_STRI
On 2021-09-03 16:16, Sven Peter wrote:
On Thu, Sep 2, 2021, at 21:42, Robin Murphy wrote:
On 2021-09-02 19:19, Sven Peter wrote:
On Wed, Sep 1, 2021, at 23:10, Alyssa Rosenzweig wrote:
My biggest issue is that I do not understand how this function is supposed
to be used correctly. It
On 2021-09-02 19:19, Sven Peter wrote:
On Wed, Sep 1, 2021, at 23:10, Alyssa Rosenzweig wrote:
My biggest issue is that I do not understand how this function is supposed
to be used correctly. It would work fine as-is if it only ever gets passed
buffers
allocated by the coherent API but there'
On 2021-09-02 13:51, Anders Roxell wrote:
On Wed, 1 Sept 2021 at 11:58, Robin Murphy wrote:
On 2021-09-01 09:59, Marek Szyprowski wrote:
On 21.05.2021 05:03, Wang Xingang wrote:
From: Xingang Wang
When booting with devicetree, the pci_request_acs() is called after the
enumeration and
On 2021-09-01 18:14, Sven Peter wrote:
On Tue, Aug 31, 2021, at 23:39, Alyssa Rosenzweig wrote:
+ if ((1 << __ffs(domain->pgsize_bitmap)) > PAGE_SIZE) {
Not a fan of this construction. Could you assign `(1 <<
__ffs(domain->pgsize_bitmap))` to an appropriately named temporary (e.g
min_i
On 2021-09-01 09:59, Marek Szyprowski wrote:
On 21.05.2021 05:03, Wang Xingang wrote:
From: Xingang Wang
When booting with devicetree, the pci_request_acs() is called after the
enumeration and initialization of PCI devices, thus the ACS is not
enabled. And ACS should be enabled when IOMMU is d
On 2021-08-26 16:17, Lucas Stach wrote:
Am Donnerstag, dem 26.08.2021 um 16:00 +0100 schrieb Robin Murphy:
On 2021-08-26 13:10, Michael Walle wrote:
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an
On 2021-08-26 13:10, Michael Walle wrote:
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an IOMMU:
[5.191008] Failed to set up IOMMU for device (null); retaining platform DMA
ops
This is because there is
implementations do.
This avoids repeated warnings on a small minority of systems where the
display is behind an IOMMU, and has a simple driver which does not
override drm_gem_cma_default_funcs.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 +
1 file changed, 1 insertion
On 2021-08-24 14:55, Geert Uytterhoeven wrote:
Hi Robin,
On Fri, Aug 20, 2021 at 3:22 PM Robin Murphy wrote:
Previously io-pgtable merely passed the iommu_iotlb_gather pointer
through to helpers, but now it has grown its own direct dereference.
This turns out to break the build for !IOMMU_API
Hi Geert,
On 2021-08-24 14:25, Geert Uytterhoeven wrote:
Hi Robin,
On Wed, Aug 11, 2021 at 2:24 PM Robin Murphy wrote:
IO_PGTABLE_QUIRK_NON_STRICT was never a very comfortable fit, since it's
not a quirk of the pagetable format itself. Now that we have a more
appropriate way to conve
Hi,
FWIW this patch itself looks fine, but it does highlight some things
which could be further cleaned up if anyone's interested...
On 2021-08-22 22:06, Christophe JAILLET wrote:
[...]
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
ind
On 2021-08-23 22:30, Christophe JAILLET wrote:
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
Si
Hi,
FWIW this patch itself looks fine, but it does highlight some things
which could be further cleaned up if anyone's interested...
On 2021-08-22 22:06, Christophe JAILLET wrote:
[...]
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
ind
e the gather mechanism and simply pass in NULL.
Wrap this dereference in a suitable helper which can both be stubbed
out for !IOMMU_API and encapsulate a NULL check otherwise.
Fixes: 7a7c5badf858 ("iommu: Indicate queued flushes via gather data")
Reported-by: kernel test robot
Signed-off-b
On 2021-08-17 02:38, David Stevens wrote:
From: David Stevens
For devices which set min_align_mask, swiotlb preserves the offset of
the original physical address within that mask. Since __iommu_dma_map
accounts for non-aligned addresses, passing a non-aligned swiotlb
address with the swiotlb al
On 2021-08-17 02:38, David Stevens wrote:
From: David Stevens
Fold the _swiotlb helper functions into the respective _page functions,
since recent fixes have moved all logic from the _page functions to the
_swiotlb functions.
Reviewed-by: Robin Murphy
Signed-off-by: David Stevens
iommu_dma_sync_sg_for_cpu for untrusted devices in iommu_dma_unmap_sg no
longer necessary, so move that invocation later in the function.
Reviewed-by: Robin Murphy
Signed-off-by: David Stevens
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 11 ++-
1 file changed, 6 insertions(+), 5
efore mapping never
really worked, since it needs to be able to target swiotlb buffers.
This also moves the architectural sync to before the call to
__iommu_dma_map, to guarantee that untrusted devices can't see stale
data they shouldn't see.
Reviewed-by: Robin Murphy
Fixes: 82612
On 2021-08-18 12:29, Joerg Roedel wrote:
On Wed, Aug 11, 2021 at 01:21:14PM +0100, Robin Murphy wrote:
Robin Murphy (24):
iommu: Pull IOVA cookie management into the core
iommu/amd: Drop IOVA cookie management
iommu/arm-smmu: Drop IOVA cookie management
iommu/vt-d: Drop IOVA cookie
On 2021-08-17 12:34, Zhen Lei wrote:
Although the parameter 'cmd' is always passed by a local array variable,
and only this function modifies it, the compiler does not know this. The
compiler almost always reads the value of cmd[i] from memory rather than
directly using the value cached in the re
On 2021-08-16 07:48, Sven Peter wrote:
On Thu, Aug 12, 2021, at 13:29, Joerg Roedel wrote:
Hi Sven,
On Tue, Aug 10, 2021 at 08:09:53AM +0200, Sven Peter wrote:
This happens because apple/dart is missing the "Optimizing iommu_[map/unmap]
performance"
series which is already in the core branc
On 2021-08-13 17:47, Will Deacon wrote:
Hi Joerg,
Please pull these Arm SMMU updates for 5.15. There's not tonnes here, but
a good mixture of optimisations and cleanups -- summary in the tag.
This applies cleanly against iommu/next, but I suspect it will conflict
with Robin's series on the list
On 2021-08-11 12:48, Zhen Lei wrote:
The obvious key to the performance optimization of commit 587e6c10a7ce
("iommu/arm-smmu-v3: Reduce contention during command-queue insertion") is
to allow multiple cores to insert commands in parallel after a brief mutex
contention.
Obviously, inserting as ma
..@lst.de/
[2] https://lwn.net/Articles/801230/
Thank you all.
Best Regards,
-邮件原件-----
发件人: Robin Murphy
发送时间: 2021年8月13日 17:16
收件人: Jichao Zou ; David Hildenbrand ;
a...@linux-foundation.org; linux-ker...@vger.kernel.org; linux...@kvack.org; minc...@kernel.org;
song.bao@hisilicon.com; h.
On 2021-08-13 09:27, Jichao Zou wrote:
Hi David,
I'll git-send-email patch again.
Your understanding is exactly right.
Let me explain the background of Patch, we are developing Android
phone, kernel is 5.10.43 LTS, we encounter cma_alloc failed during kernel
startup, bud
On 2021-08-11 21:18, Sven Peter wrote:
On Tue, Aug 10, 2021, at 11:51, Robin Murphy wrote:
On 2021-08-09 21:45, Sven Peter wrote:
On Mon, Aug 9, 2021, at 19:41, Robin Murphy wrote:
On 2021-08-07 12:47, Sven Peter via iommu wrote:
On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
On
On 2021-08-12 10:21, David Stevens wrote:
On Thu, Aug 12, 2021 at 3:47 AM Robin Murphy wrote:
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
When calling arch_sync_dma, we need to pass it the memory that's
actually being used for dma. When using swiotlb bounce buffers,
On 2021-08-12 02:45, David Stevens wrote:
On Thu, Aug 12, 2021 at 4:12 AM Robin Murphy wrote:
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
For devices which set min_align_mask, swiotlb preserves the offset of
the original physical address within that mask. Since
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
For devices which set min_align_mask, swiotlb preserves the offset of
the original physical address within that mask. Since __iommu_dma_map
accounts for non-aligned addresses, passing a non-aligned swiotlb
address with the swiotlb al
-by: Robin Murphy
Signed-off-by: David Stevens
---
drivers/iommu/dma-iommu.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index be0214b1455c..89b689bf801f 100644
--- a/drivers/iommu/dma
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
After syncing in map/unmap, add the DMA_ATTR_SKIP_CPU_SYNC flag so
anything that uses attrs later on will skip any sync work that has
already been completed. In particular, this skips copying from the
swiotlb twice during unmap.
Sig
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
When calling arch_sync_dma, we need to pass it the memory that's
actually being used for dma. When using swiotlb bounce buffers, this is
the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb
helper, so it can use the
e above check and fold the if (!dev_is_dma_coherent(dev))
into the else line. Same for iommu_dma_sync_sg_for_device.
+1
With those also cleaned up,
Reviewed-by: Robin Murphy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2021-08-11 11:30, Will Deacon wrote:
On Wed, Aug 11, 2021 at 11:37:25AM +0530, Sai Prakash Ranjan wrote:
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index f7da8953afbe..3904b598e0f9 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/driver
such a clear use-case for tightening
up security *after* the device may already have done whatever it is that
you don't trust it not to do, so we only consider the relaxation case.
Signed-off-by: Robin Murphy
---
v3: Actually think about concurrency, rework most of the fq data
accesse
To parallel the sysfs behaviour, merge the new build-time option
for DMA domain strictness into the default domain type choice.
Suggested-by: Joerg Roedel
Reviewed-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
Reviewed-by: John Garry
Signed-off-by: Robin Murphy
---
v3: Remember to update
ce as well.
Reviewed-by: Lu Baolu
Reviewed-by: John Garry
Signed-off-by: Robin Murphy
---
v3: Summarise the implications in the documentation for completeness
---
Documentation/ABI/testing/sysfs-kernel-iommu_groups | 6 +-
drivers/iommu/iommu.c | 2 ++
2
Garry
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b141161d5bbc..63face36fc49 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu
.
- Ensures that we only end up using flush queues for drivers
which are aware of them and can actually benefit.
- Allows us to handle flush queue init failure by falling back
to strict mode instead of leaving it to possibly blow up later.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
801 - 900 of 5518 matches
Mail list logo
