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
Hi Baolu,
On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote:
> I have no preference. It depends on which patch goes first. Let the
> maintainers help here.
No preference on my side, except that it is too late for this now to
make it into v5.10. Besides that I let the decission up to you wh
ot;iommu/vt-d: Delegate the dma domain to upper layer"), but
> the error looks older.
>
> Fixes: fa954e683178 ("iommu/vt-d: Delegate the dma domain to upper layer")
> Signed-off-by: Chris Wilson
> Cc: James Sewart
> Cc: Lu Baolu
> Cc: Joerg Roedel
> Cc: # v5
On Sat, Aug 22, 2020 at 12:31:55PM +0100, Chris Wilson wrote:
> The active ingredient was
>
> 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
Right, that is what bisection will point to. Thanks for collecting all
the info and updating the commit message!
Regards,
Joerg
On Fri, Aug 21, 2020 at 12:18:41PM -0700, Linus Torvalds wrote:
> It also strikes me that I think the only architecture that uses the
> whole arch_sync_kernel_mappings() thing is now just x86-32.
>
> [ Well, x86-64 still has it, but that's because we undid the 64-bit
> removal, but it's on the ver
From: Joerg Roedel
The __apply_to_page_range() function is also used to change and/or
allocate page-table pages in the vmalloc area of the address space.
Make sure these changes get synchronized to other page-tables in the
system by calling arch_sync_kernel_mappings() when necessary.
Tested-by
On Fri, Aug 21, 2020 at 12:38:03PM +0100, Chris Wilson wrote:
> In the version I tested, I also had
>
> @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
>
> if (create) {
> pte = (mm == &init_mm) ?
> - pte_alloc
On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> We need to store the initial addr, as here addr == end [or earlier on
> earlier], so range is (start, addr).
Right, I missed that, thanks for pointing it out.
___
Intel-gfx mailing list
Inte
On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote:
> Ok. I thought it had to be after assigning the *ptep. If we apply the
> sync first, do not have to worry about PGTBL_PTE_MODIFIED from the
> *ptep?
Hmm, if I understand the code correctly, you are re-implementing some
generic ioremap/
The __apply_to_page_range() function is also used to change and/or
allocate page-table pages in the vmalloc area of the address space.
Make sure these changes get synchronized to other page-tables in the
system by calling arch_sync_kernel_mappings() when necessary.
Signed-off-by: Joerg Roedel
().
>
> Reported-by: Pavel Machek
> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were
> modified")
> References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
>
On Thu, Jun 25, 2020 at 03:08:23PM +0200, Joerg Roedel wrote:
> Joerg Roedel (13):
> iommu/exynos: Use dev_iommu_priv_get/set()
> iommu/vt-d: Use dev_iommu_priv_get/set()
> iommu/msm: Use dev_iommu_priv_get/set()
> iommu/omap: Use dev_iommu_priv_get/set()
> i
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/device.h b/arch/x86
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 --
drivers/iommu/intel/iommu.c|
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/rockchip-iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/io
From: Joerg Roedel
The iommu private pointer is already used in the Mediatek IOMMU v1
driver, so move the dma_iommu_mapping pointer into 'struct
mtk_iommu_data' and do not use dev->archdata.iommu anymore.
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.h| 2 ++
From: Joerg Roedel
Hi,
here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures which no longer need it.
On PowerPC
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 8
drivers/iommu/tegra-smmu.c | 8
2 files changed, 8 insertions(+), 8 deleti
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/msm_iommu.
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/include/asm/device.h b/arch
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/ia64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/ia64/include/asm/device.h b/arch
From: Joerg Roedel
Remove the use of dev->archdata.iommu_domain and use the private
per-device pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu_domain.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/io
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/exynos-iommu.c | 20 +--
.../media/platform/s5p-mfc/s5p_mfc_iommu.h|
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/driv
From: Joerg Roedel
There are no users left, so remove the pointer and save some memory.
Signed-off-by: Joerg Roedel
---
arch/powerpc/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index
On Mon, Sep 09, 2019 at 12:00:10PM +0100, Chris Wilson wrote:
> drivers/iommu/intel-iommu.c | 44 +
> 1 file changed, 35 insertions(+), 9 deletions(-)
Applied, thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freede
On Sat, Jul 20, 2019 at 07:08:48PM +0100, Chris Wilson wrote:
> ---
> drivers/iommu/iova.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied to iommu/fixes.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fre
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote:
> We have many reports where just having intel_iommu=on (and using the
> system normally, without any virtualization stuff going on) will cause
> unexplained GPU hangs. For those users, simply switching to
> intel_iommu=igfx_off solve
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would no
Hi Daniel,
On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> Note that the string of platforms which have various issues with iommu
> and igfx is very long, thus far we only disabled it where there's no
> workaround to stop it from hanging the box, but otherwise left it
> enabled. S
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, q
On Mon, Jul 09, 2018 at 10:36:43AM +0200, Daniel Vetter wrote:
> #define for_each_active_drhd_unit(drhd)
> \
> list_for_each_entry_rcu(drhd, &dmar_drhd_units, list) \
> - if (drhd->ignored) {} else
> + for_each_if (!drhd
; - obj = acpi_evaluate_dsm_typed(handle, dmar_hp_uuid, DMAR_DSM_REV_ID,
> + obj = acpi_evaluate_dsm_typed(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID,
> func, NULL, ACPI_TYPE_BUFFER);
> if (!obj)
> return -ENODEV;
DM
On Mon, Jun 06, 2016 at 02:20:11PM +0200, Jan Niehusmann wrote:
> The valid range of 'did' in get_iommu_domain(*iommu, did)
> is 0..cap_ndoms(iommu->cap), so don't exceed that
> range in free_all_cpu_cached_iovas().
>
> The user-visible impact of the out-of-bounds access is the machine
> hanging o
On Sun, Jun 26, 2016 at 12:54:19PM +0200, Thorsten Leemhuis wrote:
> Joerg, what's the status here? This made it on my 4.7 regressions
> report, as the patches from this thread are supposed to fix a
> regression; see
> http://thread.gmane.org/gmane.linux.usb.general/143504/focus=153154
> for detail
On Wed, Jun 01, 2016 at 12:10:08PM +0100, Chris Wilson wrote:
> drivers/iommu/iova.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Okay, applied this patch to iommu/fixes and will send it upstream this
week.
___
Intel-gfx mailing list
t; v2: convert preempt_disable(); var = this_cpu_ptr() to var = get_cpu_ptr()
> v3: Actually use get_cpu_ptr (not get_cpu_var). Drop the spinlock
> removal, concentrate on the immediate bug fix.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96293
> Signed-off-by: Chris Wilson
&
On Wed, Jun 01, 2016 at 12:10:09PM +0100, Chris Wilson wrote:
> By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
> having a spinlock inside the per-cpu struct. The only place where we
> actually may touch another CPU's data is when performing a cache flush
> after running out of
Adding David and Jiang, they might have an idea whats going wrong.
On Fri, Oct 17, 2014 at 05:17:16PM -0400, Dave Jones wrote:
> Just hit this while fuzz-testing, (curiously, no graphics
> related stuff was happening, X isn't even loaded on that box).
>
> dmar: DRHD: handling fault status reg 2
>
On Fri, Jun 20, 2014 at 01:43:50PM +0200, Joerg Roedel wrote:
> Change_pte is also called when the underlying page of an address
> changes in the kernel which would matter for DMA. But that can only
> happen in KSM and uprobes code which is probably not of interest for the
> i915 driv
On Thu, Jun 19, 2014 at 05:02:57PM +0100, Chris Wilson wrote:
> Maybe it should hook the invalidate_page notifier. I picked
> invalidate_range() as it seemed to be called first and seemed to cover
> all operations that affected an mm's addr range. The invalidate_page
> seemed to be only called dur
Hey Chris,
recently I had a look at i915_gem_userptr.c in order to extend the
mmu_notifier call-backs implemented there. My goal is to implement the
change_pte call-back where it is necessary to get rid of it being
wrapped mn_invalidate_range_start/end() calls (for the reason see
commit 6bdb913f).
43 matches
Mail list logo
