Re: [Intel-gfx] [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api
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 together with this conversion, it can be reverted and will not be in 5.11-final. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api
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 when this is ready. Just send me a pull-request when it should get into the iommu-tree. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: Handle 36b addressing for x86-32
On Sat, Aug 22, 2020 at 05:02:09PM +0100, Chris Wilson wrote:
> Beware that the address size for x86-32 may exceed unsigned long.
>
> [0.368971] UBSAN: shift-out-of-bounds in
> drivers/iommu/intel/iommu.c:128:14
> [0.369055] shift exponent 36 is too large for 32-bit type 'long unsigned
> int'
>
> If we don't handle the wide addresses, the pages are mismapped and the
> device read/writes go astray, detected as DMAR faults and leading to
> device failure. The behaviour changed (from working to broken) in commit
> fa954e683178 ("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.3+
> ---
> drivers/iommu/intel/iommu.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Applied for v5.9, thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
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 verge of going away and x86-64 shouldn't > actually _need_ it any more ] > > So all of this seems to be purely for 32-bit x86. Which kind of makes > this all fail the smell test. Yeah, it is certainly not the nicest thing to have in generic mm code, but at least it is an improvement of the vmalloc_sync_all() interface we had before, where the function had to be called at random undefined places. And x86-32 needs it, as long as we have the !SHARED_KERNEL_PMD cases (which includes legacy paging). Or we also pre-allocate the PMDs on x86-32 and forbid large ioremap mappings. But since the vmalloc area gets larger with less RAM on x86-32, this would penalize low memory machines by using more pages for the pre-allocations. Not sure if making the vmalloc area on x86-32 a fixed 128MB range of address space independent of RAM size is doable or if it will break some machines. But with that pre-allocating PMDs would make more sense and we could get rid of the p?d_alloc_track() stuff. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
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: Chris Wilson #x86-32
Cc: # v5.8+
Signed-off-by: Joerg Roedel
---
mm/memory.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 3a7779d9891d..1b7d846f6992 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -83,6 +83,7 @@
#include
#include
+#include "pgalloc-track.h"
#include "internal.h"
#if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST)
@@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory);
static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pte_t *pte;
int err = 0;
@@ -2214,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
if (create) {
pte = (mm == &init_mm) ?
- pte_alloc_kernel(pmd, addr) :
+ pte_alloc_kernel_track(pmd, addr, mask) :
pte_alloc_map_lock(mm, pmd, addr, &ptl);
if (!pte)
return -ENOMEM;
@@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
break;
}
} while (addr += PAGE_SIZE, addr != end);
+ *mask |= PGTBL_PTE_MODIFIED;
arch_leave_lazy_mmu_mode();
@@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pmd_t *pmd;
unsigned long next;
@@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t
*pud,
BUG_ON(pud_huge(*pud));
if (create) {
- pmd = pmd_alloc(mm, pud, addr);
+ pmd = pmd_alloc_track(mm, pud, addr, mask);
if (!pmd)
return -ENOMEM;
} else {
@@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t
*pud,
next = pmd_addr_end(addr, end);
if (create || !pmd_none_or_clear_bad(pmd)) {
err = apply_to_pte_range(mm, pmd, addr, next, fn, data,
-create);
+create, mask);
if (err)
break;
}
@@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm,
pud_t *pud,
static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pud_t *pud;
unsigned long next;
int err = 0;
if (create) {
- pud = pud_alloc(mm, p4d, addr);
+ pud = pud_alloc_track(mm, p4d, addr, mask);
if (!pud)
return -ENOMEM;
} else {
@@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t
*p4d,
next = pud_addr_end(addr, end);
if (create || !pud_none_or_clear_bad(pud)) {
err = apply_to_pmd_range(mm, pud, addr, next, fn, data,
-create);
+create, mask);
if (err)
break;
}
@@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm,
p4d_t *p4d,
static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
p4d_t *p4d;
unsigned long next;
int err = 0;
if (create) {
-
Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction
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_kernel(pmd, addr) :
> + pte_alloc_kernel_track(pmd, addr, mask) :
> pte_alloc_map_lock(mm, pmd, addr, &ptl);
> if (!pte)
> return -ENOMEM;
>
> And that PGTBL_PMD_MODIFIED makes a difference.
Right, thanks. Added that too.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction
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 Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction
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/vmalloc mapping logic in the i915 driver. I don't know the reason, but if it is valid you need to manually call arch_sync_kernel_mappings() from your driver like this to be correct: if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED) arch_sync_kernel_mappings(); In practice this is a no-op, because nobody sets PGTBL_PTE_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK, so the above code would be optimized away. But what you really care about is the tracking in apply_to_page_range(), as that allocates the !pte levels of your page-table, which needs synchronization on x86-32. Btw, what are the reasons you can't use generic vmalloc/ioremap interfaces to map the range? Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction
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
---
(Only compile tested on x86-64 so far)
mm/memory.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 3a7779d9891d..fd845991f14a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -83,6 +83,7 @@
#include
#include
+#include "pgalloc-track.h"
#include "internal.h"
#if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST)
@@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory);
static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pte_t *pte;
int err = 0;
@@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
break;
}
} while (addr += PAGE_SIZE, addr != end);
+ *mask |= PGTBL_PTE_MODIFIED;
arch_leave_lazy_mmu_mode();
@@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pmd_t *pmd;
unsigned long next;
@@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t
*pud,
BUG_ON(pud_huge(*pud));
if (create) {
- pmd = pmd_alloc(mm, pud, addr);
+ pmd = pmd_alloc_track(mm, pud, addr, mask);
if (!pmd)
return -ENOMEM;
} else {
@@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t
*pud,
next = pmd_addr_end(addr, end);
if (create || !pmd_none_or_clear_bad(pmd)) {
err = apply_to_pte_range(mm, pmd, addr, next, fn, data,
-create);
+create, mask);
if (err)
break;
}
@@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm,
pud_t *pud,
static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
pud_t *pud;
unsigned long next;
int err = 0;
if (create) {
- pud = pud_alloc(mm, p4d, addr);
+ pud = pud_alloc_track(mm, p4d, addr, mask);
if (!pud)
return -ENOMEM;
} else {
@@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t
*p4d,
next = pud_addr_end(addr, end);
if (create || !pud_none_or_clear_bad(pud)) {
err = apply_to_pmd_range(mm, pud, addr, next, fn, data,
-create);
+create, mask);
if (err)
break;
}
@@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm,
p4d_t *p4d,
static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data, bool create)
+pte_fn_t fn, void *data, bool create,
+pgtbl_mod_mask *mask)
{
p4d_t *p4d;
unsigned long next;
int err = 0;
if (create) {
- p4d = p4d_alloc(mm, pgd, addr);
+ p4d = p4d_alloc_track(mm, pgd, addr, mask);
if (!p4d)
return -ENOMEM;
} else {
@@ -2318,7 +2324,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t
*pgd,
next = p4d_addr_end(addr, end);
if (create || !p4d_none_or_clear_bad(p4d)) {
err = apply_to_pud_range(m
Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction
On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> The alloc_vm_area() is another method for drivers to
> vmap/map_kernel_range that uses apply_to_page_range() rather than the
> direct vmalloc walkers. This is missing the page table modification
> tracking, and the ability to synchronize the PTE updates afterwards.
> Provide flush_vm_area() for the users of alloc_vm_area() that assumes
> the worst and ensures that the page directories are correctly flushed
> upon construction.
>
> The impact is most pronounced on x86_32 due to the delayed set_pmd().
>
> 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
> Cc: Joerg Roedel
> Cc: Linus Torvalds
> Cc: Dave Airlie
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Pavel Machek
> Cc: David Vrabel
> Cc: # v5.8+
> ---
> include/linux/vmalloc.h | 1 +
> mm/vmalloc.c| 16
> 2 files changed, 17 insertions(+)
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 0221f852a7e1..a253b27df0ac 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr)
>
> /* Allocate/destroy a 'vmalloc' VM area. */
> extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
> +extern void flush_vm_area(struct vm_struct *area);
> extern void free_vm_area(struct vm_struct *area);
>
> /* for /dev/kmem */
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b482d240f9a2..c41934486031 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t
> **ptes)
> }
> EXPORT_SYMBOL_GPL(alloc_vm_area);
>
> +void flush_vm_area(struct vm_struct *area)
> +{
> + unsigned long addr = (unsigned long)area->addr;
> +
> + /* apply_to_page_range() doesn't track the damage, assume the worst */
> + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED |
> + PGTBL_PMD_MODIFIED |
> + PGTBL_PUD_MODIFIED |
> + PGTBL_P4D_MODIFIED |
> + PGTBL_PGD_MODIFIED))
> + arch_sync_kernel_mappings(addr, addr + area->size);
This should happen in __apply_to_page_range() directly and look like
this:
if (ARCH_PAGE_TABLE_SYNC_MASK && create)
arch_sync_kernel_mappings(addr, addr + size);
Or even better, track whether something had to be allocated in the
__apply_to_page_range() path and check for:
if (ARCH_PAGE_TABLE_SYNC_MASK & mask)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu
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() > iommu/rockchip: Use dev_iommu_priv_get/set() > iommu/tegra: Use dev_iommu_priv_get/set() > iommu/pamu: Use dev_iommu_priv_get/set() > iommu/mediatek: Do no use dev->archdata.iommu > x86: Remove dev->archdata.iommu pointer > ia64: Remove dev->archdata.iommu pointer > arm: Remove dev->archdata.iommu pointer > arm64: Remove dev->archdata.iommu pointer > powerpc/dma: Remove dev->archdata.iommu_domain Applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/13] x86: Remove dev->archdata.iommu pointer
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/include/asm/device.h
index 49bd6cf3eec9..7c0a52ca2f4d 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -3,9 +3,6 @@
#define _ASM_X86_DEVICE_H
struct dev_archdata {
-#ifdef CONFIG_IOMMU_API
- void *iommu; /* hook for IOMMU specific extension */
-#endif
};
struct pdev_archdata {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/13] iommu/vt-d: Use dev_iommu_priv_get/set()
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| 18 +-
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 9b105b811f1f..e08601905a64 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
@@ -118,6 +119,9 @@ struct drm_i915_private *mock_gem_device(void)
{
struct drm_i915_private *i915;
struct pci_dev *pdev;
+#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
+ struct dev_iommu iommu;
+#endif
int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
@@ -136,8 +140,10 @@ struct drm_i915_private *mock_gem_device(void)
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- /* hack to disable iommu for the fake device; force identity mapping */
- pdev->dev.archdata.iommu = (void *)-1;
+ /* HACK HACK HACK to disable iommu for the fake device; force identity
mapping */
+ memset(&iommu, 0, sizeof(iommu));
+ iommu.priv = (void *)-1;
+ pdev->dev.iommu = &iommu;
#endif
pci_set_drvdata(pdev, i915);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d759e7234e98..2ce490c2eab8 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -372,7 +372,7 @@ struct device_domain_info *get_domain_info(struct device
*dev)
if (!dev)
return NULL;
- info = dev->archdata.iommu;
+ info = dev_iommu_priv_get(dev);
if (unlikely(info == DUMMY_DEVICE_DOMAIN_INFO ||
info == DEFER_DEVICE_DOMAIN_INFO))
return NULL;
@@ -743,12 +743,12 @@ struct context_entry *iommu_context_addr(struct
intel_iommu *iommu, u8 bus,
static int iommu_dummy(struct device *dev)
{
- return dev->archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO;
+ return dev_iommu_priv_get(dev) == DUMMY_DEVICE_DOMAIN_INFO;
}
static bool attach_deferred(struct device *dev)
{
- return dev->archdata.iommu == DEFER_DEVICE_DOMAIN_INFO;
+ return dev_iommu_priv_get(dev) == DEFER_DEVICE_DOMAIN_INFO;
}
/**
@@ -2420,7 +2420,7 @@ static inline void unlink_domain_info(struct
device_domain_info *info)
list_del(&info->link);
list_del(&info->global);
if (info->dev)
- info->dev->archdata.iommu = NULL;
+ dev_iommu_priv_set(info->dev, NULL);
}
static void domain_remove_dev_info(struct dmar_domain *domain)
@@ -2453,7 +2453,7 @@ static void do_deferred_attach(struct device *dev)
{
struct iommu_domain *domain;
- dev->archdata.iommu = NULL;
+ dev_iommu_priv_set(dev, NULL);
domain = iommu_get_domain_for_dev(dev);
if (domain)
intel_iommu_attach_device(domain, dev);
@@ -2599,7 +2599,7 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
list_add(&info->link, &domain->devices);
list_add(&info->global, &device_domain_list);
if (dev)
- dev->archdata.iommu = info;
+ dev_iommu_priv_set(dev, info);
spin_unlock_irqrestore(&device_domain_lock, flags);
/* PASID table is mandatory for a PCI device in scalable mode. */
@@ -4004,7 +4004,7 @@ static void quirk_ioat_snb_local_iommu(struct pci_dev
*pdev)
if (!drhd || drhd->reg_base_addr - vtbar != 0xa000) {
pr_warn_once(FW_BUG "BIOS assigned incorrect VT-d unit for
Intel(R) QuickData Technology device\n");
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
- pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
+ dev_iommu_priv_set(&pdev->dev, DUMMY_DEVICE_DOMAIN_INFO);
}
}
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SNB,
quirk_ioat_snb_local_iommu);
@@ -4043,7 +4043,7 @@ static void __init init_no_remapping_devices(void)
drhd->ignored = 1;
for_each_active_dev_scope(drhd->devices,
drhd->devices_cnt, i, dev)
- dev->archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
+ dev_iommu_priv_set(dev,
DUMMY_DEVICE_DOMAIN_INFO);
}
}
}
@@ -5665,7 +5665,7 @@ static struct iommu_device
*intel_iommu_probe_devi
[Intel-gfx] [PATCH 05/13] iommu/rockchip: Use dev_iommu_priv_get/set()
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/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index d25c2486ca07..e5d86b7177de 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -836,7 +836,7 @@ static size_t rk_iommu_unmap(struct iommu_domain *domain,
unsigned long _iova,
static struct rk_iommu *rk_iommu_from_dev(struct device *dev)
{
- struct rk_iommudata *data = dev->archdata.iommu;
+ struct rk_iommudata *data = dev_iommu_priv_get(dev);
return data ? data->iommu : NULL;
}
@@ -1059,7 +1059,7 @@ static struct iommu_device *rk_iommu_probe_device(struct
device *dev)
struct rk_iommudata *data;
struct rk_iommu *iommu;
- data = dev->archdata.iommu;
+ data = dev_iommu_priv_get(dev);
if (!data)
return ERR_PTR(-ENODEV);
@@ -1073,7 +1073,7 @@ static struct iommu_device *rk_iommu_probe_device(struct
device *dev)
static void rk_iommu_release_device(struct device *dev)
{
- struct rk_iommudata *data = dev->archdata.iommu;
+ struct rk_iommudata *data = dev_iommu_priv_get(dev);
device_link_del(data->link);
}
@@ -1100,7 +1100,7 @@ static int rk_iommu_of_xlate(struct device *dev,
iommu_dev = of_find_device_by_node(args->np);
data->iommu = platform_get_drvdata(iommu_dev);
- dev->archdata.iommu = data;
+ dev_iommu_priv_set(dev, data);
platform_device_put(iommu_dev);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/13] iommu/mediatek: Do no use dev->archdata.iommu
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 ++
drivers/iommu/mtk_iommu_v1.c | 10 --
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ea949a324e33..1682406e98dc 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -62,6 +62,8 @@ struct mtk_iommu_data {
struct iommu_device iommu;
const struct mtk_iommu_plat_data *plat_data;
+ struct dma_iommu_mapping*mapping; /* For mtk_iommu_v1.c */
+
struct list_headlist;
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index c9d79cff4d17..82ddfe9170d4 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -269,7 +269,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
int ret;
/* Only allow the domain created internally. */
- mtk_mapping = data->dev->archdata.iommu;
+ mtk_mapping = data->mapping;
if (mtk_mapping->domain != domain)
return 0;
@@ -369,7 +369,6 @@ static int mtk_iommu_create_mapping(struct device *dev,
struct mtk_iommu_data *data;
struct platform_device *m4updev;
struct dma_iommu_mapping *mtk_mapping;
- struct device *m4udev;
int ret;
if (args->args_count != 1) {
@@ -401,8 +400,7 @@ static int mtk_iommu_create_mapping(struct device *dev,
return ret;
data = dev_iommu_priv_get(dev);
- m4udev = data->dev;
- mtk_mapping = m4udev->archdata.iommu;
+ mtk_mapping = data->mapping;
if (!mtk_mapping) {
/* MTK iommu support 4GB iova address space. */
mtk_mapping = arm_iommu_create_mapping(&platform_bus_type,
@@ -410,7 +408,7 @@ static int mtk_iommu_create_mapping(struct device *dev,
if (IS_ERR(mtk_mapping))
return PTR_ERR(mtk_mapping);
- m4udev->archdata.iommu = mtk_mapping;
+ data->mapping = mtk_mapping;
}
return 0;
@@ -459,7 +457,7 @@ static void mtk_iommu_probe_finalize(struct device *dev)
int err;
data= dev_iommu_priv_get(dev);
- mtk_mapping = data->dev->archdata.iommu;
+ mtk_mapping = data->mapping;
err = arm_iommu_attach_device(dev, mtk_mapping);
if (err)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu
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 the field is called dev->archdata.iommu_domain and was only used by the PAMU IOMMU driver. It gets removed as well. The patches have been runtime tested on Intel VT-d and compile tested with allyesconfig for: * x86 (32 and 64 bit) * arm and arm64 * ia64 (only drivers/ because build failed for me in arch/ia64) * PPC64 Besides that the changes also survived my IOMMU tree compile tests. Please review. Regards, Joerg 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() iommu/rockchip: Use dev_iommu_priv_get/set() iommu/tegra: Use dev_iommu_priv_get/set() iommu/pamu: Use dev_iommu_priv_get/set() iommu/mediatek: Do no use dev->archdata.iommu x86: Remove dev->archdata.iommu pointer ia64: Remove dev->archdata.iommu pointer arm: Remove dev->archdata.iommu pointer arm64: Remove dev->archdata.iommu pointer powerpc/dma: Remove dev->archdata.iommu_domain arch/arm/include/asm/device.h | 3 --- arch/arm64/include/asm/device.h | 3 --- arch/ia64/include/asm/device.h| 3 --- arch/powerpc/include/asm/device.h | 3 --- arch/x86/include/asm/device.h | 3 --- .../gpu/drm/i915/selftests/mock_gem_device.c | 10 -- drivers/iommu/exynos-iommu.c | 20 +-- drivers/iommu/fsl_pamu_domain.c | 8 drivers/iommu/intel/iommu.c | 18 - drivers/iommu/msm_iommu.c | 4 ++-- drivers/iommu/mtk_iommu.h | 2 ++ drivers/iommu/mtk_iommu_v1.c | 10 -- drivers/iommu/omap-iommu.c| 20 +-- drivers/iommu/rockchip-iommu.c| 8 drivers/iommu/tegra-gart.c| 8 drivers/iommu/tegra-smmu.c| 8 .../media/platform/s5p-mfc/s5p_mfc_iommu.h| 4 +++- 17 files changed, 64 insertions(+), 71 deletions(-) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/13] arm: Remove dev->archdata.iommu pointer
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/include/asm/device.h
index c675bc0d5aa8..be666f58bf7a 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -9,9 +9,6 @@ struct dev_archdata {
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
-#ifdef CONFIG_IOMMU_API
- void *iommu; /* private IOMMU data */
-#endif
#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping*mapping;
#endif
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/13] iommu/tegra: Use dev_iommu_priv_get/set()
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 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 5fbdff6ff41a..fac720273889 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -113,8 +113,8 @@ static int gart_iommu_attach_dev(struct iommu_domain
*domain,
if (gart->active_domain && gart->active_domain != domain) {
ret = -EBUSY;
- } else if (dev->archdata.iommu != domain) {
- dev->archdata.iommu = domain;
+ } else if (dev_iommu_priv_get(dev) != domain) {
+ dev_iommu_priv_set(dev, domain);
gart->active_domain = domain;
gart->active_devices++;
}
@@ -131,8 +131,8 @@ static void gart_iommu_detach_dev(struct iommu_domain
*domain,
spin_lock(&gart->dom_lock);
- if (dev->archdata.iommu == domain) {
- dev->archdata.iommu = NULL;
+ if (dev_iommu_priv_get(dev) == domain) {
+ dev_iommu_priv_set(dev, NULL);
if (--gart->active_devices == 0)
gart->active_domain = NULL;
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 7426b7666e2b..124c8848ab7e 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -465,7 +465,7 @@ static void tegra_smmu_as_unprepare(struct tegra_smmu *smmu,
static int tegra_smmu_attach_dev(struct iommu_domain *domain,
struct device *dev)
{
- struct tegra_smmu *smmu = dev->archdata.iommu;
+ struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
struct tegra_smmu_as *as = to_smmu_as(domain);
struct device_node *np = dev->of_node;
struct of_phandle_args args;
@@ -780,7 +780,7 @@ static struct iommu_device *tegra_smmu_probe_device(struct
device *dev)
* supported by the Linux kernel, so abort after the
* first match.
*/
- dev->archdata.iommu = smmu;
+ dev_iommu_priv_set(dev, smmu);
break;
}
@@ -797,7 +797,7 @@ static struct iommu_device *tegra_smmu_probe_device(struct
device *dev)
static void tegra_smmu_release_device(struct device *dev)
{
- dev->archdata.iommu = NULL;
+ dev_iommu_priv_set(dev, NULL);
}
static const struct tegra_smmu_group_soc *
@@ -856,7 +856,7 @@ static struct iommu_group *tegra_smmu_group_get(struct
tegra_smmu *smmu,
static struct iommu_group *tegra_smmu_device_group(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct tegra_smmu *smmu = dev->archdata.iommu;
+ struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
struct iommu_group *group;
group = tegra_smmu_group_get(smmu, fwspec->ids[0]);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/13] iommu/msm: Use dev_iommu_priv_get/set()
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.c b/drivers/iommu/msm_iommu.c
index 3d8a63555c25..f773cc85f311 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -593,14 +593,14 @@ static void insert_iommu_master(struct device *dev,
struct msm_iommu_dev **iommu,
struct of_phandle_args *spec)
{
- struct msm_iommu_ctx_dev *master = dev->archdata.iommu;
+ struct msm_iommu_ctx_dev *master = dev_iommu_priv_get(dev);
int sid;
if (list_empty(&(*iommu)->ctx_list)) {
master = kzalloc(sizeof(*master), GFP_ATOMIC);
master->of_node = dev->of_node;
list_add(&master->list, &(*iommu)->ctx_list);
- dev->archdata.iommu = master;
+ dev_iommu_priv_set(dev, master);
}
for (sid = 0; sid < master->num_mids; sid++)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] arm64: Remove dev->archdata.iommu pointer
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/arm64/include/asm/device.h
index 12b778d55342..996498751318 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -6,9 +6,6 @@
#define __ASM_DEVICE_H
struct dev_archdata {
-#ifdef CONFIG_IOMMU_API
- void *iommu;/* private IOMMU data */
-#endif
};
struct pdev_archdata {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/13] ia64: Remove dev->archdata.iommu pointer
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/ia64/include/asm/device.h
index 3eb397415381..918b198cd5bb 100644
--- a/arch/ia64/include/asm/device.h
+++ b/arch/ia64/include/asm/device.h
@@ -6,9 +6,6 @@
#define _ASM_IA64_DEVICE_H
struct dev_archdata {
-#ifdef CONFIG_IOMMU_API
- void *iommu; /* hook for IOMMU specific extension */
-#endif
};
struct pdev_archdata {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/13] iommu/pamu: Use dev_iommu_priv_get/set()
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/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 928d37771ece..b2110767caf4 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -323,7 +323,7 @@ static void remove_device_ref(struct device_domain_info
*info, u32 win_cnt)
pamu_disable_liodn(info->liodn);
spin_unlock_irqrestore(&iommu_lock, flags);
spin_lock_irqsave(&device_domain_lock, flags);
- info->dev->archdata.iommu_domain = NULL;
+ dev_iommu_priv_set(info->dev, NULL);
kmem_cache_free(iommu_devinfo_cache, info);
spin_unlock_irqrestore(&device_domain_lock, flags);
}
@@ -352,7 +352,7 @@ static void attach_device(struct fsl_dma_domain
*dma_domain, int liodn, struct d
* Check here if the device is already attached to domain or not.
* If the device is already attached to a domain detach it.
*/
- old_domain_info = dev->archdata.iommu_domain;
+ old_domain_info = dev_iommu_priv_get(dev);
if (old_domain_info && old_domain_info->domain != dma_domain) {
spin_unlock_irqrestore(&device_domain_lock, flags);
detach_device(dev, old_domain_info->domain);
@@ -371,8 +371,8 @@ static void attach_device(struct fsl_dma_domain
*dma_domain, int liodn, struct d
* the info for the first LIODN as all
* LIODNs share the same domain
*/
- if (!dev->archdata.iommu_domain)
- dev->archdata.iommu_domain = info;
+ if (!dev_iommu_priv_get(dev))
+ dev_iommu_priv_set(dev, info);
spin_unlock_irqrestore(&device_domain_lock, flags);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/13] iommu/exynos: Use dev_iommu_priv_get/set()
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| 4 +++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 60c8a56e4a3f..6a9b67302369 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -173,7 +173,7 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
#define REG_V5_FAULT_AR_VA 0x070
#define REG_V5_FAULT_AW_VA 0x080
-#define has_sysmmu(dev)(dev->archdata.iommu != NULL)
+#define has_sysmmu(dev)(dev_iommu_priv_get(dev) != NULL)
static struct device *dma_dev;
static struct kmem_cache *lv2table_kmem_cache;
@@ -226,7 +226,7 @@ static const struct sysmmu_fault_info sysmmu_v5_faults[] = {
};
/*
- * This structure is attached to dev.archdata.iommu of the master device
+ * This structure is attached to dev->iommu->priv of the master device
* on device add, contains a list of SYSMMU controllers defined by device tree,
* which are bound to given master device. It is usually referenced by 'owner'
* pointer.
@@ -670,7 +670,7 @@ static int __maybe_unused exynos_sysmmu_suspend(struct
device *dev)
struct device *master = data->master;
if (master) {
- struct exynos_iommu_owner *owner = master->archdata.iommu;
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(master);
mutex_lock(&owner->rpm_lock);
if (data->domain) {
@@ -688,7 +688,7 @@ static int __maybe_unused exynos_sysmmu_resume(struct
device *dev)
struct device *master = data->master;
if (master) {
- struct exynos_iommu_owner *owner = master->archdata.iommu;
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(master);
mutex_lock(&owner->rpm_lock);
if (data->domain) {
@@ -837,8 +837,8 @@ static void exynos_iommu_domain_free(struct iommu_domain
*iommu_domain)
static void exynos_iommu_detach_device(struct iommu_domain *iommu_domain,
struct device *dev)
{
- struct exynos_iommu_owner *owner = dev->archdata.iommu;
struct exynos_iommu_domain *domain = to_exynos_domain(iommu_domain);
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
phys_addr_t pagetable = virt_to_phys(domain->pgtable);
struct sysmmu_drvdata *data, *next;
unsigned long flags;
@@ -875,8 +875,8 @@ static void exynos_iommu_detach_device(struct iommu_domain
*iommu_domain,
static int exynos_iommu_attach_device(struct iommu_domain *iommu_domain,
struct device *dev)
{
- struct exynos_iommu_owner *owner = dev->archdata.iommu;
struct exynos_iommu_domain *domain = to_exynos_domain(iommu_domain);
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
struct sysmmu_drvdata *data;
phys_addr_t pagetable = virt_to_phys(domain->pgtable);
unsigned long flags;
@@ -1237,7 +1237,7 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
iommu_domain *iommu_domain,
static struct iommu_device *exynos_iommu_probe_device(struct device *dev)
{
- struct exynos_iommu_owner *owner = dev->archdata.iommu;
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
struct sysmmu_drvdata *data;
if (!has_sysmmu(dev))
@@ -1263,7 +1263,7 @@ static struct iommu_device
*exynos_iommu_probe_device(struct device *dev)
static void exynos_iommu_release_device(struct device *dev)
{
- struct exynos_iommu_owner *owner = dev->archdata.iommu;
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
struct sysmmu_drvdata *data;
if (!has_sysmmu(dev))
@@ -1287,8 +1287,8 @@ static void exynos_iommu_release_device(struct device
*dev)
static int exynos_iommu_of_xlate(struct device *dev,
struct of_phandle_args *spec)
{
- struct exynos_iommu_owner *owner = dev->archdata.iommu;
struct platform_device *sysmmu = of_find_device_by_node(spec->np);
+ struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
struct sysmmu_drvdata *data, *entry;
if (!sysmmu)
@@ -1305,7 +1305,7 @@ static int exynos_iommu_of_xlate(struct device *dev,
INIT_LIST_HEAD(&owner->controllers);
mutex_init(&owner->rpm_lock);
- dev->archdata.iommu = owner;
+ dev_iommu_priv_set(dev, owner);
}
list_for_each_entry(entry, &owner->controllers, owner_node)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
b/drivers/media
[Intel-gfx] [PATCH 04/13] iommu/omap: Use dev_iommu_priv_get/set()
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/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c8282cc212cb..e84ead6fb234 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -71,7 +71,7 @@ static struct omap_iommu_domain *to_omap_domain(struct
iommu_domain *dom)
**/
void omap_iommu_save_ctx(struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
struct omap_iommu *obj;
u32 *p;
int i;
@@ -101,7 +101,7 @@ EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
**/
void omap_iommu_restore_ctx(struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
struct omap_iommu *obj;
u32 *p;
int i;
@@ -1398,7 +1398,7 @@ static size_t omap_iommu_unmap(struct iommu_domain
*domain, unsigned long da,
static int omap_iommu_count(struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
int count = 0;
while (arch_data->iommu_dev) {
@@ -1459,8 +1459,8 @@ static void omap_iommu_detach_fini(struct
omap_iommu_domain *odomain)
static int
omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
{
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
struct omap_iommu_domain *omap_domain = to_omap_domain(domain);
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
struct omap_iommu_device *iommu;
struct omap_iommu *oiommu;
int ret = 0;
@@ -1524,7 +1524,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct
device *dev)
static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain,
struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
struct omap_iommu_device *iommu = omap_domain->iommus;
struct omap_iommu *oiommu;
int i;
@@ -1650,7 +1650,7 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
int num_iommus, i;
/*
-* Allocate the archdata iommu structure for DT-based devices.
+* Allocate the per-device iommu structure for DT-based devices.
*
* TODO: Simplify this when removing non-DT support completely from the
* IOMMU users.
@@ -1698,7 +1698,7 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
of_node_put(np);
}
- dev->archdata.iommu = arch_data;
+ dev_iommu_priv_set(dev, arch_data);
/*
* use the first IOMMU alone for the sysfs device linking.
@@ -1712,19 +1712,19 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
static void omap_iommu_release_device(struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
if (!dev->of_node || !arch_data)
return;
- dev->archdata.iommu = NULL;
+ dev_iommu_priv_set(dev, NULL);
kfree(arch_data);
}
static struct iommu_group *omap_iommu_device_group(struct device *dev)
{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+ struct omap_iommu_arch_data *arch_data = dev_iommu_priv_get(dev);
struct iommu_group *group = ERR_PTR(-EINVAL);
if (!arch_data)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/13] powerpc/dma: Remove dev->archdata.iommu_domain
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 266542769e4b..1bc595213338 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -34,9 +34,6 @@ struct dev_archdata {
struct iommu_table *iommu_table_base;
#endif
-#ifdef CONFIG_IOMMU_API
- void*iommu_domain;
-#endif
#ifdef CONFIG_PPC64
struct pci_dn *pci_data;
#endif
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] iommu/intel: Declare Broadwell igfx dmar support snafu
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.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/iova: Remove stale cached32_node
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.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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 solves the problems, and the debug often ends > there. If you can reproduce problems on your side, then you can try to enable CONFIG_INTEL_IOMMU_BROKEN_GFX_WA to force the GFX devices into the identity mapping. We can also add a boot-parameter and workarounds if it turns out that this is sufficient to make the GFX devices work with IOMMU enabled. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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 not be using the iGFX device. You can force the igfx device into a SI domain, or does that also trigger the iommu issues on the chipset? In any case, if iommu=on breaks these systems I want to make them work again with opt-out, even at the cost of breaking assignability. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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. So if we make a policy change to also disable it anywhere > where it doesn't work well (instead of not at all), there's a pile > more platforms to switch. I think its best to just disable iommu for the igfx devices on these platforms. Can you pick up Eric's patch and extend it with the list of affected platforms? Thanks, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_g4x_gfx);
>
> static void quirk_iommu_rwbf(struct pci_dev *dev)
> {
> @@ -5457,7 +5458,6 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev
> *dev)
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
> quirk_calpella_no_shadow_gtt);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> quirk_calpella_no_shadow_gtt);
This seems to make sense to me. Joonas, any comments or objections?
Regards,
Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] dmar: Use for_each_If
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->ignored)
Hmm, in my tree the macro comes from
include/drm/drmP.h:#define for_each_if(condition) if (!(condition)) {}
else
Please re-submit when the macro is in a generic header upstream.
Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index cbf7763d8091..420d51b286ad 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu);
> * for Directed-IO Architecture Specifiction, Rev 2.2, Section 8.8
> * "Remapping Hardware Unit Hot Plug".
> */
> -static u8 dmar_hp_uuid[] = {
> - /* */0xA6, 0xA3, 0xC1, 0xD8, 0x9B, 0xBE, 0x9B, 0x4C,
> - /* 0008 */0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF
> -};
> +static uuid_le dmar_hp_uuid =
> + UUID_LE(0xD8C1A3A6, 0xBE9B, 0x4C9B,
> + 0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF);
>
> /*
> * Currently there's only one revision and BIOS will not check the revision
> id,
> @@ -1824,7 +1823,7 @@ static u8 dmar_hp_uuid[] = {
>
> static inline bool dmar_detect_dsm(acpi_handle handle, int func)
> {
> - return acpi_check_dsm(handle, dmar_hp_uuid, DMAR_DSM_REV_ID, 1 << func);
> + return acpi_check_dsm(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID, 1 <<
> func);
> }
>
> static int dmar_walk_dsm_resource(acpi_handle handle, int func,
> @@ -1843,7 +1842,7 @@ static int dmar_walk_dsm_resource(acpi_handle handle,
> int func,
> if (!dmar_detect_dsm(handle, func))
> return 0;
>
> - 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;
DMAR part is
Acked-by: Joerg Roedel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] iommu/vt-d: fix overflow of iommu->domains array
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 on suspend-to-ram. It is, in fact, a kernel panic, but due
> to already suspended devices, that's often not visible to the user.
>
> Fixes: 22e2f9fa63b0 ("iommu/vt-d: Use per-cpu IOVA caching")
> Signed-off-by: Jan Niehusmann
> Tested-By: Marius Vlad
Queued to iommu/fixes branch, thanks Jan.
Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()
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 details. > > Please let me know if if fixes went to mainline already; I did a quick > check and could see any. Okay, queued the fix, should be upstream for -rc6. > Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo) > Thorsten Awesome, glad to see you picking this up :) Cheers, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()
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 Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()
On Wed, Jun 01, 2016 at 12:10:08PM +0100, Chris Wilson wrote: > Between acquiring the this_cpu_ptr() and using it, ideally we don't want > to be preempted and work on another CPU's private data. this_cpu_ptr() > checks whether or not preemption is disable, and get_cpu_ptr() provides > a convenient wrapper for operating on the cpu ptr inside a preemption > disabled critical section (which currently is provided by the > spinlock). Indeed if we disable preemption around this_cpu_ptr, > we do not need the CPU local spinlock - so long as take care that no other > CPU is running that code as do perform the cross-CPU cache flushing and > teardown, but that is a subject for another patch. > > [ 167.997877] BUG: using smp_processor_id() in preemptible [] code: > usb-storage/216 > [ 167.997940] caller is debug_smp_processor_id+0x17/0x20 > [ 167.997945] CPU: 7 PID: 216 Comm: usb-storage Tainted: G U > 4.7.0-rc1-gfxbench-RO_Patchwork_1057+ #1 > [ 167.997948] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS > 8.11 10/24/2012 > [ 167.997951] 880118b7f9c8 8140dca5 > 0007 > [ 167.997958] 81a3a7e9 880118b7f9f8 8142a927 > > [ 167.997965] 8800d499ed58 0001 000f > 880118b7fa08 > [ 167.997971] Call Trace: > [ 167.997977] [] dump_stack+0x67/0x92 > [ 167.997981] [] check_preemption_disabled+0xd7/0xe0 > [ 167.997985] [] debug_smp_processor_id+0x17/0x20 > [ 167.997990] [] alloc_iova_fast+0xb7/0x210 > [ 167.997994] [] intel_alloc_iova+0x7f/0xd0 > [ 167.997998] [] intel_map_sg+0xbd/0x240 > [ 167.998002] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 > [ 167.998009] [] usb_hcd_map_urb_for_dma+0x4b9/0x5a0 > [ 167.998013] [] usb_hcd_submit_urb+0xe9/0xaa0 > [ 167.998017] [] ? mark_held_locks+0x6f/0xa0 > [ 167.998022] [] ? __raw_spin_lock_init+0x1c/0x50 > [ 167.998025] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 > [ 167.998028] [] usb_submit_urb+0x3f3/0x5a0 > [ 167.998032] [] ? trace_hardirqs_on_caller+0x122/0x1b0 > [ 167.998035] [] usb_sg_wait+0x67/0x150 > [ 167.998039] [] > usb_stor_bulk_transfer_sglist.part.3+0x82/0xd0 > [ 167.998042] [] usb_stor_bulk_srb+0x4c/0x60 > [ 167.998045] [] usb_stor_Bulk_transport+0x17e/0x420 > [ 167.998049] [] usb_stor_invoke_transport+0x242/0x540 > [ 167.998052] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 > [ 167.998058] [] > usb_stor_transparent_scsi_command+0x9/0x10 > [ 167.998061] [] usb_stor_control_thread+0x158/0x260 > [ 167.998064] [] ? fill_inquiry_response+0x20/0x20 > [ 167.998067] [] ? fill_inquiry_response+0x20/0x20 > [ 167.998071] [] kthread+0xea/0x100 > [ 167.998078] [] ret_from_fork+0x1f/0x40 > [ 167.998081] [] ? kthread_create_on_node+0x1f0/0x1f0 > > 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 > Cc: Joonas Lahtinen > Cc: Joerg Roedel > Cc: io...@lists.linux-foundation.org > Cc: linux-ker...@vger.kernel.org > --- > drivers/iommu/iova.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c > index ba764a0835d3..e23001bfcfee 100644 > --- a/drivers/iommu/iova.c > +++ b/drivers/iommu/iova.c > @@ -420,8 +420,10 @@ retry: > > /* Try replenishing IOVAs by flushing rcache. */ > flushed_rcache = true; > + preempt_disable(); > for_each_online_cpu(cpu) > free_cpu_cached_iovas(cpu, iovad); > + preempt_enable(); Why do you need to disable preemption here? The free_cpu_cached_iovas function does not need to stay on the same cpu as it iterates over the rcaches for all cpus anyway. Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] iommu: Remove cpu-local spinlock
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 memory. Here, we can instead schedule a task to run > on the other CPU to do the flush before trying again. The big benefit of the spinlock is that the rcache can be flushed from a different cpu without the need to send IPIs to everyone. Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] dmar messages caused by graphics.
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 > dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7ff000 > DMAR:[fault reason 05] PTE Write access is not set > > > 00:02:0 is.. > > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th > Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 > [VGA controller]) > > 00: 86 80 12 04 07 04 90 00 06 00 00 03 00 00 00 00 > 10: 04 00 00 c0 00 00 00 00 0c 00 00 b0 00 00 00 00 > 20: 01 30 00 00 00 00 00 00 00 00 00 00 86 80 12 22 > 30: 00 00 00 00 90 00 00 00 00 00 00 00 0b 01 00 00 > > > So then I rebooted, and noticed it spewed the exact same message on boot up > too. > > I power cycled, and this time got > > [0.576231] dmar: Host address width 39 > [0.576336] dmar: DRHD base: 0x00fed9 flags: 0x0 > [0.576491] dmar: IOMMU 0: reg_base_addr fed9 ver 1:0 cap > c020660462 ecap f0101a > [0.576659] dmar: DRHD base: 0x00fed91000 flags: 0x1 > [0.576793] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap > d2008020660462 ecap f010da > [0.576961] dmar: RMRR base: 0x00a2a1f000 end: 0x00a2a32fff > [0.577075] dmar: RMRR base: 0x00ad80 end: 0x00af9f > [6.715745] DMAR: No ATSR found > [8.081845] [drm] DMAR active, disabling use of stolen memory > [9.927343] dmar: DRHD: handling fault status reg 2 > [9.928335] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 3c11284000 > DMAR:[fault reason 05] PTE Write access is not set > [ 11.916211] dmar: DRHD: handling fault status reg 2 > [ 11.917105] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 3c11284000 > DMAR:[fault reason 05] PTE Write access is not set > > > Same thing, different fault address. It seems to change every time I boot. > > > Looking in the logs, this started happening on the 15th. The first instance > was this during boot.. > > [9.917240] dmar: DRHD: handling fault status reg 2 > [9.918150] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 73 > [9.918150] DMAR:[fault reason 05] PTE Write access is not set > [9.919582] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 7ff000 > [9.919582] DMAR:[fault reason 05] PTE Write access is not set > [ 10.157240] dmar: DRHD: handling fault status reg 3 > [ 10.158017] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 3579736000 > [ 10.158017] DMAR:[fault reason 05] PTE Write access is not set > [ 11.926114] dmar: DRHD: handling fault status reg 3 > [ 11.927117] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > 73 > [ 11.927117] DMAR:[fault reason 05] PTE Write access is not set > > That time, the 'reg 3' showed up. > > Dying hardware ? Or bug ? > > Dave > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] mmu_notifier and i915_gem_userptr.c
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 driver. > > The other case where I think it matters is the do_wp_page() path for > COW. The code works by calling invalidate_range_start -> change_pte -> > invalidate_range_end. Your driver would react to this by unbinding the > vma from itself internally (after a fork for example). > > But I have to check whether this really matters here. Okay, I think it does not matter for the i915 driver. The code-paths which map pages read-only for COW invoke invalidate_range_start/end on the page-ranges which causes the driver to unbind the pages. When get_user_pages() is called again later it will do the COW by itself, so the driver doesn't need to care. So I tend to say that the i915 driver does not need a change_pte() call-back at all. But probably someone should double-check to make sure I didn't miss something. Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] mmu_notifier and i915_gem_userptr.c
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 during writeback, which aiui will not affect gup. > Should we be hooking more notifiers? For what you are interested in the invalidate_range_start notifier should be sufficient. Invalidate_page is only called for page-aging and swapping (and xip, but that doesn't matter either). The problem with invalidate_range_start/end is that its semantics make it somewhat expensive to implement. So it would be good to reduce the call-sites and get rid of it at least around the change_pte calls in a first step. > > I am not familiar with the i915 hardware and the driver implementation > > details, so I wanted to ask whether the driver > > > > 1) Cares about the change_pte event? > > I don't think so... If I understand correctly, change_pte only gets > called when the PTE is updated, not the physical page itself. If that is > true, then the dma mapping of the page is unaffected, and so the GPU > view of the page is not affected either. So, as long as the GPU > maintains a remapped address of a page that is associated by a process > address, we don't need to change anything. 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 driver. The other case where I think it matters is the do_wp_page() path for COW. The code works by calling invalidate_range_start -> change_pte -> invalidate_range_end. Your driver would react to this by unbinding the vma from itself internally (after a fork for example). But I have to check whether this really matters here. > If need be, start with overkill. I'd rather drop everything and rebuild > it through the layers of mappings we have, as this is a new area for us > and we want some solid foundations before trying to be smart. The main problem I have seen so far is the mutex taken in the invalidate_range_start call-back. That can't be used in a change_pte function because change_pte is not preemptible. Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] mmu_notifier and i915_gem_userptr.c
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). For most users of mmu_notifiers this is easy, except the i915 driver :) The invalidate_range_start notifier implemented there can sleep, so it can't be reused for a change_pte implementation (because change_pte is called under ptl spin_lock and is not allowed to sleep). On the other hand you also didn't implement the invalidate_page notifier, so I am not sure whether the code actually cares about the somewhat similar change_pte events? Here is where change_pte is called from: * In KSM code when pages are merged (shouldn't be relevant because KSM doesn't merged pages returned by get_user_pages()) * In uprobes code when a user-page is replaced by a kernel page (should only handle .text sections, so probaly not relevant here) * When someone writes to a COW page in mm/memory.c (this looks relevant looking at forked processes, on the other hand, this is currently handled by unbinding the vma from the object list in the i915 driver) I am not familiar with the i915 hardware and the driver implementation details, so I wanted to ask whether the driver 1) Cares about the change_pte event? 2) If it cares, what is the best way to implement it? What the invalidate_range_start() notifier does seems a bit overkill, since for the change_pte event nothing is unmapped (but maybe remapped) So any insight you could provide here would be useful :) Thanks, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
