On Thurs, Nov 26, 2020, at 9:27 AM, Lu Baolu wrote:
> Add the API for getting the domain from a vfio group. This could be used
> by the physical device drivers which rely on the vfio/mdev framework for
> mediated device user level access. The typical use case like below:
>
> unsigned int
When changing from a set of pages/smaller blocks to a larger block for an
address, the software should follow the sequence of BBML processing.
When changing from a block to a set of pages/smaller blocks for an
address, there's no need to use nT bit. If an address in the large block
is accessed
On 2020/11/25 19:35, Will Deacon wrote:
On Wed, Nov 25, 2020 at 09:54:34AM +0800, Yang Yingliang wrote:
On 2020/11/18 6:41, Will Deacon wrote:
On Tue, Nov 17, 2020 at 07:11:28PM +0800, Yang Yingliang wrote:
On 2020/11/17 17:40, Lu Baolu wrote:
On 2020/11/17 10:52, Yang Yingliang wrote:
If
Add the API for getting the domain from a vfio group. This could be used
by the physical device drivers which rely on the vfio/mdev framework for
mediated device user level access. The typical use case like below:
unsigned int pasid;
struct vfio_group *vfio_group;
struct
On Wed, Nov 25, 2020 at 10:27:49AM +0100, Jean-Philippe Brucker wrote:
> > I'm strongly
> > trying to discourage static lists matching mm's like smmu_mn is
> > doing. This is handled by the core code, don't open code it..
>
> We discussed this at v6, which wonkily stored the mn ops in the domain
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_sgtable().
With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().
Hi
On 25.11.2020 21:31, Ricardo Ribalda wrote:
> On architectures where the is no coherent caching such as ARM use the
> dma_alloc_noncontiguos API and handle manually the cache flushing using
> dma_sync_sg().
>
> With this patch on the affected architectures we can measure up to 20x
>
On Wed, Nov 25, 2020 at 06:24:13PM +, Robin Murphy wrote:
> On 2020-11-25 17:29, Robin Murphy wrote:
> >The only user of tlb_flush_leaf is a particularly hairy corner of the
> >Arm short-descriptor code, which wants a synchronous invalidation to
> >minimise the races inherent in trying to
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_sg().
With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().
Is there a reason we check the requested guest address width against the
iommu's mgaw, instead of the agaw that we already know for the iommu?
I've run into a case with a new system where the mgaw reported is 57,
but if they set PAE to 46 instead of 52 in the bios, then sagaw reports
the highest
On 25/11/2020 18:29, Christoph Hellwig wrote:
> I'll fold this one in as well.
>
OK, so two SoB's disappear?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
I'll fold this one in as well.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Ooops, that was my edit. I'll make sure to fold the fix into the
original commit.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Thursday, November 26, 2020 3:05 AM
> To: Song Bao Hua (Barry Song) ; Christoph
> Hellwig ; Marek Szyprowski ;
> Robin Murphy ; iommu@lists.linux-foundation.org
> Cc: kernel-janit...@vger.kernel.org;
On 2020-11-25 17:29, Robin Murphy wrote:
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Thursday, November 26, 2020 2:56 AM
> To: Song Bao Hua (Barry Song) ; Christoph
> Hellwig ; Marek Szyprowski ;
> Robin Murphy ; iommu@lists.linux-foundation.org
> Cc: kernel-janit...@vger.kernel.org;
On 2020-11-25 15:50, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a NXP specific hook to preserve SMMU mappings present at
boot time (created by the boot loader). These are needed for
MC firmware present on some NXP chips to continue working
across kernel boot and SMMU
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be dragons" territory that no
sensible caller should
[AMD Public Use]
> -Original Message-
> From: Merger, Edgar [AUTOSOL/MAS/AUGS]
>
> Sent: Wednesday, November 25, 2020 5:04 AM
> To: Deucher, Alexander ; Huang, Ray
> ; Kuehling, Felix
> Cc: Will Deacon ; linux-ker...@vger.kernel.org; linux-
> p...@vger.kernel.org;
On 2020-11-19 06:18, Yong Wu wrote:
MediaTek TLB flush don't care about granule. when unmap, it could gather
whole the iova range then do tlb flush once.
In current v7s, If unmap the lvl2 pagetable, the steps are:
step1: set this current pdg to 0.
step2: tlb flush for this lvl2 block iova(1M).
On 2020-11-19 06:18, Yong Wu wrote:
Add a granule_ignore option when tlb gather for some HW which don't care
about granule when it flush tlb.
Signed-off-by: Yong Wu
---
include/linux/iommu.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/iommu.h
On 2020-11-19 06:18, Yong Wu wrote:
Remove IO_PGTABLE_QUIRK_TLBI_ON_MAP to avoid tlb sync for each a small
chunk memory, Use the new iotlb_sync_map to tlb_sync once for whole the
iova range of iommu_map.
Signed-off-by: Yong Wu
---
After reading msm_iommu.c, It looks
On 2020-11-19 06:18, Yong Wu wrote:
iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole
mapping. This patch adds iova and size as the parameters in it. then the
IOMMU driver could flush tlb with the whole range once after iova mapping
to improve performance.
Reviewed-by:
On 2020-11-19 06:18, Yong Wu wrote:
In the end of __iommu_map, It alway call iotlb_sync_map.
This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_sync_map
is flush tlb all currently.
I don't see a way to avoid the
On Wed, Nov 25, 2020 at 03:51:30PM +, Will Deacon wrote:
> Hi Konrad,
>
> On Wed, Nov 25, 2020 at 10:41:53AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2020 at 02:05:15PM +, Will Deacon wrote:
> > > On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wrote:
> > > > After commit
From: Laurentiu Tudor
Add a NXP specific hook to preserve SMMU mappings present at
boot time (created by the boot loader). These are needed for
MC firmware present on some NXP chips to continue working
across kernel boot and SMMU initialization.
Signed-off-by: Laurentiu Tudor
---
Hi Konrad,
On Wed, Nov 25, 2020 at 10:41:53AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2020 at 02:05:15PM +, Will Deacon wrote:
> > On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wrote:
> > > After commit 327d5b2fee91c ("iommu/vt-d: Allow 32bit devices to uses DMA
> > > domain"),
On Wed, Nov 25, 2020 at 02:05:15PM +, Will Deacon wrote:
> On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wrote:
> > After commit 327d5b2fee91c ("iommu/vt-d: Allow 32bit devices to uses DMA
> > domain"), swiotbl could also be used for direct memory access if IOMMU
> > is enabled but a device is
On Wed, 25 Nov 2020 12:30:09 +0530, Sai Prakash Ranjan wrote:
> Some hardware variants contain a system 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
On Wed, 25 Nov 2020 12:30:09 +0530, Sai Prakash Ranjan wrote:
> Some hardware variants contain a system 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
From: Colin Ian King
An incorrect sizeof() is being used, sizeof(tsk) is not correct, it should
be sizeof(*tsk). Fix it.
Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
Fixes: bfd2defed94d ("dma-mapping: add benchmark support for streaming DMA
APIs")
Signed-off-by: Colin Ian King
On Wed, 25 Nov 2020 02:10:08 -0800, Nicolin Chen wrote:
> Changelog
> v1->v2:
> * Added Thierry's acks to PATCH-3~5
>
> This is a merged set of resend for previously two series of patches
> that were reviewed/acked a month ago yet have not got applied.
>
> [...]
Applied to arm64
On Tue, 24 Nov 2020 16:20:50 +0800, Lu Baolu wrote:
> The v5 of this series could be found here.
>
> https://lore.kernel.org/linux-iommu/20201120101719.3172693-1-baolu...@linux.intel.com/
>
> Changes in this version:
> - Rebase the series to the latest iommu/next branch.
>
On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wrote:
> After commit 327d5b2fee91c ("iommu/vt-d: Allow 32bit devices to uses DMA
> domain"), swiotbl could also be used for direct memory access if IOMMU
> is enabled but a device is configured to pass through the DMA translation.
> Keep swiotlb when
On Tue, 24 Nov 2020 21:06:00 +0800, Lu Baolu wrote:
> The last post of this series:
>
> https://lore.kernel.org/linux-iommu/20201121135620.3496419-1-baolu...@linux.intel.com/
>
> Change log in this series:
> 1. Changes according to comments at
>
>
From: Colin Ian King
The assignment of argp is currently using argp as the source because of
a typo. Fix this by assigning it the value passed in arg instead.
Addresses-Coverity: ("Uninitialized pointer read")
Fixes: bfd2defed94d ("dma-mapping: add benchmark support for streaming DMA
APIs")
On Thu, Nov 19, 2020 at 02:18:30PM +0800, Yong Wu wrote:
> This patchset is to improve tlb flushing performance in iommu_map/unmap
> for MediaTek IOMMU.
>
> For iommu_map, currently MediaTek IOMMU use IO_PGTABLE_QUIRK_TLBI_ON_MAP
> to do tlb_flush for each a memory chunk. this is so unnecessary.
On Wed, Nov 11, 2020 at 08:38:14PM +0800, Yong Wu wrote:
> This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
>
On Wed, Nov 25, 2020 at 09:54:34AM +0800, Yang Yingliang wrote:
>
> On 2020/11/18 6:41, Will Deacon wrote:
> > On Tue, Nov 17, 2020 at 07:11:28PM +0800, Yang Yingliang wrote:
> > > On 2020/11/17 17:40, Lu Baolu wrote:
> > > > On 2020/11/17 10:52, Yang Yingliang wrote:
> > > > > If
On Wed, Nov 25, 2020 at 07:03:34PM +0800, Yong Wu wrote:
> On Tue, 2020-11-24 at 11:05 +, Will Deacon wrote:
> > On Tue, Nov 24, 2020 at 05:24:44PM +0800, Yong Wu wrote:
> > > On Mon, 2020-11-23 at 12:32 +, Will Deacon wrote:
> > That said, maybe we could simplify this further by changing
On Tue, 2020-11-24 at 11:05 +, Will Deacon wrote:
> On Tue, Nov 24, 2020 at 05:24:44PM +0800, Yong Wu wrote:
> > On Mon, 2020-11-23 at 12:32 +, Will Deacon wrote:
> > > On Fri, Nov 20, 2020 at 05:06:28PM +0800, Yong Wu wrote:
> > > > + unmapped_sz = 0;
> > > >
On Wed, Nov 25, 2020 at 02:10:08AM -0800, Nicolin Chen wrote:
> Changelog
> v1->v2:
> * Added Thierry's acks to PATCH-3~5
>
> This is a merged set of resend for previously two series of patches
> that were reviewed/acked a month ago yet have not got applied.
Thanks, and sorry I missed these
The bus_set_iommu() in tegra_smmu_probe() enumerates all clients
to call in tegra_smmu_probe_device() where each client searches
its DT node for smmu pointer and swgroup ID, so as to configure
an fwspec. But this requires a valid smmu pointer even before mc
and smmu drivers are probed. So in
This patch simply adds support for PCI devices.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git
In tegra_smmu_(de)attach_dev() functions, we poll DTB for each
client's iommus property to get swgroup ID in order to prepare
"as" and enable smmu. Actually tegra_smmu_configure() prepared
an fwspec for each client, and added to the fwspec all swgroup
IDs of client DT node in DTB.
So this patch
This is used to protect potential race condition at use_count.
since probes of client drivers, calling attach_dev(), may run
concurrently.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 34
The tegra_smmu_group_get was added to group devices in different
SWGROUPs and it'd return a NULL group pointer upon a mismatch at
tegra_smmu_find_group(), so for most of clients/devices, it very
likely would mismatch and need a fallback generic_device_group().
But now tegra_smmu_group_get handles
Changelog
v1->v2:
* Added Thierry's acks to PATCH-3~5
This is a merged set of resend for previously two series of patches
that were reviewed/acked a month ago yet have not got applied.
Series-1: https://lkml.org/lkml/2020/9/29/73
"[PATCH v4 0/2] iommu/tegra-smmu: Two followup changes"
On Wed, Nov 25, 2020 at 09:55:10AM +, Will Deacon wrote:
> On Tue, Nov 24, 2020 at 03:12:16PM -0800, Nicolin Chen wrote:
> > On Wed, Nov 25, 2020 at 02:05:14AM +0300, Dmitry Osipenko wrote:
> > > 25.11.2020 00:21, Nicolin Chen пишет:
> > > > These five patches were acked by Thierry and
I do have also other problems with this unit, when IOMMU is enabled and
pci=noats is not set as kernel parameter.
[ 2004.265906] amdgpu :0b:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR*
IB test failed on gfx (-110).
[ 2004.266024] [drm:amdgpu_device_delayed_init_work_handler [amdgpu]]
On Tue, Nov 24, 2020 at 03:12:16PM -0800, Nicolin Chen wrote:
> On Wed, Nov 25, 2020 at 02:05:14AM +0300, Dmitry Osipenko wrote:
> > 25.11.2020 00:21, Nicolin Chen пишет:
> > > These five patches were acked by Thierry and acked-n-tested by
> > > Dmitry a while ago. Would it be possible for you to
On Tue, Nov 24, 2020 at 07:58:00PM -0400, Jason Gunthorpe wrote:
> On Fri, Sep 18, 2020 at 12:18:52PM +0200, Jean-Philippe Brucker wrote:
>
> > +/* Allocate or get existing MMU notifier for this {domain, mm} pair */
> > +static struct arm_smmu_mmu_notifier *
> > +arm_smmu_mmu_notifier_get(struct
Remark:
Systems with R1305G APU (which show the issue) have the following
VGA-Controller:
0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Picasso (rev cf)
Systems with V1404I APU (which do not show the issue) have the following
VGA-Controller:
0b:00.0 VGA compatible
53 matches
Mail list logo
