Hi Will and Robin,
Sorry for the late reply.
On 2020/11/3 18:21, Robin Murphy wrote:
On 2020-11-03 09:11, Will Deacon wrote:
On Tue, Nov 03, 2020 at 11:00:27AM +0800, Kunkun Jiang wrote:
Recently, I have read and learned the code related to io-pgtable-arm.c.
There
are two question on arm_lpae
Hi Joerg,
On 11/3/20 9:23 PM, Joerg Roedel wrote:
Hi Baolu,
On Mon, Oct 26, 2020 at 02:30:08PM +0800, Lu Baolu wrote:
@@ -264,7 +266,8 @@ int iommu_probe_device(struct device *dev)
*/
iommu_alloc_default_domain(group, dev);
- if (group->default_domain)
+ if (group->d
On 2020-11-03 17:56, John Garry wrote:
To summarize, the issue is that as time goes by, the CPU rcache and
depot
rcache continue to grow. As such, IOVA RB tree access time also
continues
to grow.
Hi Robin,
I'm struggling to see how this is not simply indicative of a leak
originating elsew
On 06 Oct 2020 17:23, Auger Eric wrote:
> Hello Al,
>
> On 10/2/20 8:23 PM, Al Stone wrote:
> > On 24 Sep 2020 11:54, Auger Eric wrote:
> >> Hi,
> >>
> >> Adding Al in the loop
> >>
> >> On 9/24/20 11:38 AM, Michael S. Tsirkin wrote:
> >>> On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wro
On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote:
> I think the same PCI driver with a small flag to support the PF or
> VF is not the same as two completely different drivers in different
> subsystems
There are counter-examples: ixgbe vs. ixgbevf.
Note that also a single driver ca
On Tue, Nov 03, 2020 at 06:00:33PM +0100, Nicolas Saenz Julienne wrote:
> On Fri, 2020-10-30 at 18:11 +, Catalin Marinas wrote:
> > On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> > > Ard Biesheuvel (1):
> > > arm64: mm: Set ZONE_DMA size based on early IORT scan
> >
I'll get on it.
Jim
On Tue, Nov 3, 2020 at 12:42 PM Florian Fainelli wrote:
>
>
>
> On 11/3/2020 2:15 AM, Christoph Hellwig wrote:
> > Hi Florian and others,
> >
> > now that the generic DMA ranges code landed, can we switch bmips over
> > to it instead of duplicating the logic?
>
> This should
On Mon 02 Nov 12:18 CST 2020, Robin Murphy wrote:
> On 2020-11-02 17:14, Jordan Crouse wrote:
> > From: Rob Clark
> >
> > For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> > pending translations are not terminated on iova fault. Otherwise
> > a terminated CP read could hang th
To summarize, the issue is that as time goes by, the CPU rcache and depot
rcache continue to grow. As such, IOVA RB tree access time also continues
to grow.
Hi Robin,
I'm struggling to see how this is not simply indicative of a leak
originating elsewhere.
It sounds like one, but I don't t
On Tue, Nov 03, 2020 at 05:55:40PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> > This whole thread was brought up by IDXD which has a SVA driver and
> > now wants to add a vfio-mdev driver too. SVA devices that want to be
> > plugged into VMs a
On 11/3/2020 2:15 AM, Christoph Hellwig wrote:
> Hi Florian and others,
>
> now that the generic DMA ranges code landed, can we switch bmips over
> to it instead of duplicating the logic?
This should be fine, I cannot easily test the 338x chips, however as far
as PCIe goes, I believe Jim may h
We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: Christoph Hellwig
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
---
include/linux/mmzon
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge c
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Rob Herring
---
Changes since v5:
- Update address expected by test
Changes since v3:
- Remove HAS_DMA guards
drivers/of/unitt
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Rob Herring
---
Changes since v4:
-
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Jeremy Linton
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5 deleti
crashkernel might reserve memory located in ZONE_DMA. We plan to delay
ZONE_DMA's initialization after unflattening the devicetree and ACPI's
boot table initialization, so move it later in the boot process.
Specifically into mem_init(), this is the last place crashkernel will be
able to reserve the
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bott
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.
I tested this on both a RPi4 and QEMU.
---
Changes since v5:
- Unify ACPI/DT functions
Changes since v4:
- Fix of_dma_get_max_cpu_address() so it returns the last addressable
addres, no
On Mon, Nov 02, 2020 at 06:18:45PM +, Robin Murphy wrote:
> On 2020-11-02 17:14, Jordan Crouse wrote:
> >From: Rob Clark
> >
> >For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> >pending translations are not terminated on iova fault. Otherwise
> >a terminated CP read could h
On Fri, 2020-10-30 at 18:11 +, Catalin Marinas wrote:
> On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> > Ard Biesheuvel (1):
> > arm64: mm: Set ZONE_DMA size based on early IORT scan
> >
> > Nicolas Saenz Julienne (6):
> > arm64: mm: Move reserve_crashkernel() in
On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> This whole thread was brought up by IDXD which has a SVA driver and
> now wants to add a vfio-mdev driver too. SVA devices that want to be
> plugged into VMs are going to be common - this architecture that a SVA
> driver cannot cove
On 2020-10-26 17:31, John Garry wrote:
Leizhen reported some time ago that IOVA performance may degrade over time
[0], but unfortunately his solution to fix this problem was not given
attention.
To summarize, the issue is that as time goes by, the CPU rcache and depot
rcache continue to grow. As
On 2020-11-03 14:31, John Garry wrote:
On 03/11/2020 12:35, Robin Murphy wrote:
On 2020-09-30 08:44, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache i
On Tue, Nov 03, 2020 at 03:35:32PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> > The point is that other places beyond VFIO need this
>
> Which and why?
>
> > Sure, but sometimes it is necessary, and in those cases the answer
> > can't be "rew
On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> The point is that other places beyond VFIO need this
Which and why?
> Sure, but sometimes it is necessary, and in those cases the answer
> can't be "rewrite a SVA driver to use vfio"
This is getting to abstract. Can you come up w
On 03/11/2020 12:35, Robin Murphy wrote:
On 2020-09-30 08:44, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still s
On Tue, Nov 03, 2020 at 03:03:18PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> > Userspace needs fine grained control over the composition of the page
> > table behind the PASID, 1:1 with the mm_struct is only one use case.
>
> VFIO already of
On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> Userspace needs fine grained control over the composition of the page
> table behind the PASID, 1:1 with the mm_struct is only one use case.
VFIO already offers an interface for that. It shouldn't be too
complicated to expand that
On Tue, Nov 03, 2020 at 01:16:23PM +0300, Dan Carpenter wrote:
> The "data->flags" variable is a u64 so if one of the high 32 bits is
> set the original code will allow it, but it should be rejected. The
> fix is to declare "mask" as a u64 instead of a u32.
>
> Fixes: d90573812eea ("iommu/uapi: H
On Fri, Oct 30, 2020 at 10:37:22AM +0800, Yi Sun wrote:
> We found a few issues about PRQ. So, two patches are cooked to
> fix them. Please have a review. Thanks!
>
> Changes from v1:
>
> - Modify subject of patch 1 to make it more accurate.
> - Move get_domain_info() up to the sa
Hi Suravee,
On Wed, Oct 28, 2020 at 11:18:24PM +, Suravee Suthikulpanit wrote:
> AMD IOMMU requires 4k-aligned pages for the event log, the PPR log,
> and the completion wait write-back regions. However, when allocating
> the pages, they could be part of large mapping (e.g. 2M) page.
> This ca
On Wed, Oct 28, 2020 at 03:07:25PM +0800, Lu Baolu wrote:
> Fixes: e2726daea583d ("iommu/vt-d: debugfs: Add support to show page table
> internals")
> Cc: sta...@vger.kernel.org#v5.6+
> Reported-and-tested-by: Xu Pengfei
> Signed-off-by: Lu Baolu
Applied for v5.10, thanks.
On Tue, Nov 03, 2020 at 02:18:52PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> > On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > > So having said this, what is the benefit of exposing those SVA internals
> > > to user-space
Hi Baolu,
On Mon, Oct 26, 2020 at 02:30:08PM +0800, Lu Baolu wrote:
> @@ -264,7 +266,8 @@ int iommu_probe_device(struct device *dev)
>*/
> iommu_alloc_default_domain(group, dev);
>
> - if (group->default_domain)
> + if (group->default_domain &&
> + !iommu_is_attach_
On Thu, Oct 15, 2020 at 02:50:02AM +, Suravee Suthikulpanit wrote:
> Certain device drivers allocate IO queues on a per-cpu basis.
> On AMD EPYC platform, which can support up-to 256 cpu threads,
> this can exceed the current MAX_IRQ_PER_TABLE limit of 256,
> and result in the error message:
>
On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > So having said this, what is the benefit of exposing those SVA internals
> > to user-space?
>
> Only the device use of the PASID is device specific, the actual PA
On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> So having said this, what is the benefit of exposing those SVA internals
> to user-space?
Only the device use of the PASID is device specific, the actual PASID
and everything on the IOMMU side is generic.
There is enough API there
On 2020-09-30 08:44, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still see iova alloc failure even after retry as
On 2020-09-27 07:34, Lu Baolu wrote:
Combining the sg segments exposes a bug in the Intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value specifying the number
Hi,
On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote:
> Would that work for you? We intend to send the feature pull requests
> to DRM for 5.11 in the upcoming weeks.
For the IOMMU side it is best to include the workaround for now. When
the DRM fixes are merged into v5.11-rc1 togeth
On 2020-11-03 09:11, Will Deacon wrote:
On Tue, Nov 03, 2020 at 11:00:27AM +0800, Kunkun Jiang wrote:
Recently, I have read and learned the code related to io-pgtable-arm.c.
There
are two question on arm_lpae_install_table.
1、the first
static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iop
The "data->flags" variable is a u64 so if one of the high 32 bits is
set the original code will allow it, but it should be rejected. The
fix is to declare "mask" as a u64 instead of a u32.
Fixes: d90573812eea ("iommu/uapi: Handle data and argsz filled by users")
Signed-off-by: Dan Carpenter
---
Hi Florian and others,
now that the generic DMA ranges code landed, can we switch bmips over
to it instead of duplicating the logic?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Quoting Tvrtko Ursulin (2020-11-03 11:14:32)
>
>
> On 03/11/2020 02:53, Lu Baolu wrote:
> > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
> >>
> >> On 02/11/2020 02:00, Lu Baolu wrote:
> >>> Hi Tvrtko,
> >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
>
> On 29/09/2020 01:11, Lu Baolu wrote:
Hi Jörg,
I am seeing that amdgpu uses amd_iommu_v2 kernel-module.
To me this is the last puzzle piece that was missing to explain the dependency
of that bug in amdgpu to the iommu.
[cid:image001.png@01D6B1CB.26F9C970]
Best regards
Edgar
From: Merger, Edgar [AUTOSOL/MAS/AUGS]
Sent: Freitag, 30.
Hi all,
Linux 5.10-rc1 switched from having a single dma offset in struct device
to a set of DMA ranges, and introduced a new helper to set them,
dma_direct_set_offset.
This in fact surfaced that a bunch of drivers that violate our layering
and set the offset from drivers, which meant we had to r
On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > From: Jason Wang
> > Jason suggest something like /dev/sva. There will be a lot of other
> > subsystems that could benefit from this (e.g vDPA).
Honestly, I fail to see the benefit of offloading these IOMMU specific
setup tasks to
ping?
On Fri, Oct 23, 2020 at 08:33:09AM +0200, Christoph Hellwig wrote:
> The tbl_dma_addr argument is used to check the DMA boundary for the
> allocations, and thus needs to be a dma_addr_t. swiotlb-xen instead
> passed a physical address, which could lead to incorrect results for
> strange off
On 03/11/2020 02:53, Lu Baolu wrote:
On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
On 02/11/2020 02:00, Lu Baolu wrote:
Hi Tvrtko,
On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
On 29/09/2020 01:11, Lu Baolu wrote:
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Ba
On Tue, Nov 03, 2020 at 11:00:27AM +0800, Kunkun Jiang wrote:
> Recently, I have read and learned the code related to io-pgtable-arm.c.
> There
> are two question on arm_lpae_install_table.
>
> 1、the first
>
> > static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
> >
51 matches
Mail list logo
