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
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 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
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 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
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
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
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, 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
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/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 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
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|
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
().
>
> 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
>
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
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/
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 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
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: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
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
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
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
; - 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, 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
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
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: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
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 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
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).
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
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
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
>
43 matches
Mail list logo
