> From: Lu Baolu
> Sent: Thursday, April 21, 2022 7:36 PM
>
> PRQ overflow may cause I/O throughput congestion, resulting in unnecessary
> degradation of I/O performance. Appropriately increasing the length of PRQ
> can greatly reduce the occurrence of PRQ overflow. The count of maximum
> page req
> From: Lu Baolu
> Sent: Thursday, April 21, 2022 7:36 PM
>
> The page fault handling framework in the IOMMU core explicitly states
> that it doesn't handle PCI PASID Stop Marker and the IOMMU drivers must
> discard them before reporting faults. This handles Stop Marker messages
> in prq_event_th
> From: Lu Baolu
> Sent: Thursday, April 21, 2022 7:36 PM
>
> This field make the requests snoop processor caches irrespective of
> other attributes in the request or other fields in paging structure
> entries used to translate the request.
I think you want to first point out the fact that SVA w
> From: Lu Baolu
> Sent: Thursday, April 21, 2022 7:36 PM
>
> The latest VT-d specification states that the PGSNP field in the pasid
> table entry should be treated as Reserved(0) for implementations not
> supporting Snoop Control (SC=0 in the Extended Capability Register).
> This adds a check bef
On 2022-04-21 18:35, Serge Semin wrote:
On Thu, Apr 21, 2022 at 04:45:36PM +0200, Christoph Hellwig wrote:
On Wed, Apr 20, 2022 at 11:55:38AM +0300, Serge Semin wrote:
On Wed, Apr 20, 2022 at 10:47:46AM +0200, Christoph Hellwig wrote:
I can't really comment on the dma-ranges exlcusion for P2P
On 2022-04-21 18:12, Jean-Philippe Brucker wrote:
On Thu, Apr 14, 2022 at 01:42:41PM +0100, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/virtio-iommu.c | 24
On Thu, Apr 21, 2022 at 04:45:36PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 20, 2022 at 11:55:38AM +0300, Serge Semin wrote:
> > On Wed, Apr 20, 2022 at 10:47:46AM +0200, Christoph Hellwig wrote:
> > > I can't really comment on the dma-ranges exlcusion for P2P mappings,
> > > as that predates
On Thu, Apr 14, 2022 at 01:42:41PM +0100, Robin Murphy wrote:
> Stop calling bus_set_iommu() since it's now unnecessary, and simplify
> the probe failure path accordingly.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/virtio-iommu.c | 24
> 1 file changed, 24 del
> Tegra194 and Tegra234 SoCs have the erratum that causes walk cache entries to
> not be invalidated correctly. The problem is that the walk cache index
> generated
> for IOVA is not same across translation and invalidation requests. This is
> leading
> to page faults when PMD entry is released d
On 2022-04-21 15:43, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Steven Price [mailto:steven.pr...@arm.com]
Sent: 21 April 2022 13:59
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux-foundation.org
Cc: Lin
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: 21 April 2022 07:49
> To: Shameerali Kolothum Thodi
> Cc: linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org; Linuxarm ;
> lorenzo.pieral...@arm.com; j...
On Wed, Apr 20, 2022 at 11:55:38AM +0300, Serge Semin wrote:
> On Wed, Apr 20, 2022 at 10:47:46AM +0200, Christoph Hellwig wrote:
> > I can't really comment on the dma-ranges exlcusion for P2P mappings,
> > as that predates my involvedment, however:
>
> My example wasn't specific to the PCIe P2P t
[AMD Official Use Only]
> On Wed, Apr 06, 2022 at 05:04:52PM +, Limonciello, Mario wrote:
> > Considering before this fix effectively swiotlb was turned off on most AMD
> > systems, when this is picked up I think y'all should consider to add a:
> >
> > Cc: sta...@vger.kernel.org # 5.11+
>
> A
> -Original Message-
> From: Steven Price [mailto:steven.pr...@arm.com]
> Sent: 21 April 2022 13:59
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
> j...@
On 2022-04-21 15:13, Christoph Hellwig wrote:
On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
Hi all,
Thanks to Christoph's latest series, I'm reminded that, if we're going
to give the ARM DMA ops some cleanup this cycle, it's as good a time as
any to dust off these old patches an
On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
> Hi all,
>
> Thanks to Christoph's latest series, I'm reminded that, if we're going
> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
> any to dust off these old patches and add them on top as well. I've
> based
On Thu, Apr 21, 2022 at 10:05:11AM +0200, Arnd Bergmann wrote:
> > -unsigned long __pfn_to_bus(unsigned long pfn)
> > +#else
> > +static inline unsigned long fb_bus_sdram_offset(void)
> > {
> > - return __pfn_to_phys(pfn) + (fb_bus_sdram_offset() - PHYS_OFFSET);
> > + return BUS_OFFSET
On Thu, Apr 21, 2022 at 10:00:55AM +0200, Arnd Bergmann wrote:
> I think __virt_to_bus() is now unused as well and could be removed
> in the same step.
Yes.
> It looks like __bus_to_virt() is still used in the ISA DMA API, but
> as that is only used on footbridge and rpc, the generic version of
>
On 20/04/2022 17:48, Shameer Kolothum wrote:
> Hi
>
> v9 --> v10
> - Dropped patch #1 ("Add temporary RMR node flag definitions") since
>the ACPICA header updates patch is now in the mailing list[1]
> - Based on the suggestion from Christoph, introduced a
>resv_region_free_fw_data() cal
On 2022-04-21 09:15, Ashish Mhetre wrote:
Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
entries to not be invalidated correctly. The problem is that the walk
cache index generated for IOVA is not same across translation and
invalidation requests. This is leading to page fault
PRQ overflow may cause I/O throughput congestion, resulting in unnecessary
degradation of I/O performance. Appropriately increasing the length of PRQ
can greatly reduce the occurrence of PRQ overflow. The count of maximum
page requests that can be generated in parallel by a PCIe device is
staticall
The page fault handling framework in the IOMMU core explicitly states
that it doesn't handle PCI PASID Stop Marker and the IOMMU drivers must
discard them before reporting faults. This handles Stop Marker messages
in prq_event_thread() before reporting events to the core.
The VT-d driver explicitl
This field make the requests snoop processor caches irrespective of
other attributes in the request or other fields in paging structure
entries used to translate the request.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
dif
The latest VT-d specification states that the PGSNP field in the pasid
table entry should be treated as Reserved(0) for implementations not
supporting Snoop Control (SC=0 in the Extended Capability Register).
This adds a check before setting the field.
Signed-off-by: Lu Baolu
---
drivers/iommu/i
Hi folks,
This includes several tunings of Intel SVA implementation. I plan to
target them for v5.19. Please help to review.
Best regards,
baolu
Change log:
v2:
- Move snoop control capability check into a separated patch.
- Return false if the caller opt-in setting PGSNP with a flag.
- Add
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c | 240 +-
1 file changed, 56
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c |
Hi all,
Thanks to Christoph's latest series, I'm reminded that, if we're going
to give the ARM DMA ops some cleanup this cycle, it's as good a time as
any to dust off these old patches and add them on top as well. I've
based these on the arm-dma-direct branch which I assume matches the
patches pos
On Thu, 21 Apr 2022 09:41:57 +0200
Christoph Hellwig wrote:
Hi,
> arm is the last platform not using the dma-direct code for directly
> mapped DMA. With the dmaboune removal from Arnd we can easily switch
> arm to always use dma-direct now (it already does for LPAE configs
> and nommu). I'd lo
On Wed, Apr 20, 2022 at 05:05:03PM +0100, Robin Murphy wrote:
> On 2022-04-19 15:40, Will Deacon wrote:
> > On Thu, Apr 14, 2022 at 01:42:33PM +0100, Robin Murphy wrote:
> > > Stop calling bus_set_iommu() since it's now unnecessary. With device
> > > probes now replayed for every IOMMU instance reg
Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
entries to not be invalidated correctly. The problem is that the walk
cache index generated for IOVA is not same across translation and
invalidation requests. This is leading to page faults when PMD entry is
released during unmap an
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote:
>
> Hi all,
>
> arm is the last platform not using the dma-direct code for directly
> mapped DMA. With the dmaboune removal from Arnd we can easily switch
> arm to always use dma-direct now (it already does for LPAE configs
> and nommu). I
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Use dma-direct unconditionally on arm. It has already been used for
> some time for LPAE and nommu configurations.
>
> This mostly changes the streaming mapping implementation and the (simple)
> coherent allocator for device that are DM
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Only the footbridge platforms provide their own DMA address translation
> helpers, so switch to the generic version for all other platforms, and
> consolidate the footbridge implementation to remove two levels of
> indirection.
>
> Signe
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Use the helpers as expected by the dma-direct code in the old arm
> dma-mapping code to ease a gradual switch to the common DMA code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Signed-off-by: Christoph Hellwig
I generally prefer to have at least something useful in the description, e.g.
why it's now unused and what it was used for before.
> -static inline dma_addr_t virt_to_dma(struct device *dev, void *addr
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> With the dmabounce removal these aren't used outside of dma-mapping.c,
> so mark them static. Move the dma_map_ops declarations down a bit
> to avoid lots of forward declarations.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote:
>
> Remove the now unused dmabounce code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.or
Use dma-direct unconditionally on arm. It has already been used for
some time for LPAE and nommu configurations.
This mostly changes the streaming mapping implementation and the (simple)
coherent allocator for device that are DMA coherent. The existing
complex allocator for uncached mappings for
Only the footbridge platforms provide their own DMA address translation
helpers, so switch to the generic version for all other platforms, and
consolidate the footbridge implementation to remove two levels of
indirection.
Signed-off-by: Christoph Hellwig
---
arch/arm/Kconfig
Use the helpers as expected by the dma-direct code in the old arm
dma-mapping code to ease a gradual switch to the common DMA code.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/a
Remove the now unused dmabounce code.
Signed-off-by: Christoph Hellwig
---
arch/arm/common/Kconfig| 4 -
arch/arm/common/Makefile | 1 -
arch/arm/common/dmabounce.c| 582 -
arch/arm/include/asm/device.h | 3 -
arch/arm/include/
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/dma-direct.h
b/arch/arm/include/asm/dma-direct.h
index 77fcb7ee5ec90..6fd52713b5d12 100644
--- a/arch/arm/include/asm/dma-dire
With the dmabounce removal these aren't used outside of dma-mapping.c,
so mark them static. Move the dma_map_ops declarations down a bit
to avoid lots of forward declarations.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 75 --
arch/arm/mm/dma-m
From: Arnd Bergmann
The sa platform is one of the two remaining users of the old Arm
specific "dmabounce" code, which is an earlier implementation of the
generic swiotlb.
Linus Walleij submitted a patch that removes dmabounce support from
the ixp4xx, and I had a look at the other user, which
Hi all,
arm is the last platform not using the dma-direct code for directly
mapped DMA. With the dmaboune removal from Arnd we can easily switch
arm to always use dma-direct now (it already does for LPAE configs
and nommu). I'd love to merge this series through the dma-mapping tree
as it gives u
47 matches
Mail list logo
