All of lore.kernel.org
 help / color / mirror / Atom feed
* remove alloc_vm_area v2
@ 2020-09-24 13:58 ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Hi Andrew,

this series removes alloc_vm_area, which was left over from the big
vmalloc interface rework.  It is a rather arkane interface, basicaly
the equivalent of get_vm_area + actually faulting in all PTEs in
the allocated area.  It was originally addeds for Xen (which isn't
modular to start with), and then grew users in zsmalloc and i915
which seems to mostly qualify as abuses of the interface, especially
for i915 as a random driver should not set up PTE bits directly.

Note that the i915 patches apply to the drm-tip branch of the drm-tip
tree, as that tree has recent conflicting commits in the same area.

A git tree is also available here:

    git://git.infradead.org/users/hch/misc.git alloc_vm_area

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area

Changes since v1:
 - fix a bug in the zsmalloc changes
 - fix a bug and rebase to include the recent changes in i915
 - add a new vmap flag that allows to free the page array and pages
   using vfree
 - add a vfree documentation updated from Matthew

Diffstat:
 arch/x86/xen/grant-table.c                |   27 ++++--
 drivers/gpu/drm/i915/Kconfig              |    1 
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  131 +++++++++++++-----------------
 drivers/gpu/drm/i915/gt/shmem_utils.c     |   76 ++++-------------
 drivers/xen/xenbus/xenbus_client.c        |   30 +++---
 include/linux/vmalloc.h                   |    7 -
 mm/Kconfig                                |    3 
 mm/memory.c                               |   16 ++-
 mm/nommu.c                                |    7 -
 mm/vmalloc.c                              |  123 ++++++++++++++--------------
 mm/zsmalloc.c                             |   10 +-
 11 files changed, 200 insertions(+), 231 deletions(-)

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-24 13:58 ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Hi Andrew,

this series removes alloc_vm_area, which was left over from the big
vmalloc interface rework.  It is a rather arkane interface, basicaly
the equivalent of get_vm_area + actually faulting in all PTEs in
the allocated area.  It was originally addeds for Xen (which isn't
modular to start with), and then grew users in zsmalloc and i915
which seems to mostly qualify as abuses of the interface, especially
for i915 as a random driver should not set up PTE bits directly.

Note that the i915 patches apply to the drm-tip branch of the drm-tip
tree, as that tree has recent conflicting commits in the same area.

A git tree is also available here:

    git://git.infradead.org/users/hch/misc.git alloc_vm_area

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area

Changes since v1:
 - fix a bug in the zsmalloc changes
 - fix a bug and rebase to include the recent changes in i915
 - add a new vmap flag that allows to free the page array and pages
   using vfree
 - add a vfree documentation updated from Matthew

Diffstat:
 arch/x86/xen/grant-table.c                |   27 ++++--
 drivers/gpu/drm/i915/Kconfig              |    1 
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  131 +++++++++++++-----------------
 drivers/gpu/drm/i915/gt/shmem_utils.c     |   76 ++++-------------
 drivers/xen/xenbus/xenbus_client.c        |   30 +++---
 include/linux/vmalloc.h                   |    7 -
 mm/Kconfig                                |    3 
 mm/memory.c                               |   16 ++-
 mm/nommu.c                                |    7 -
 mm/vmalloc.c                              |  123 ++++++++++++++--------------
 mm/zsmalloc.c                             |   10 +-
 11 files changed, 200 insertions(+), 231 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [PATCH 01/11] mm: update the documentation for vfree
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

From: "Matthew Wilcox (Oracle)" <willy@infradead.org>

 * Document that you can call vfree() on an address returned from vmap()
 * Remove the note about the minimum size -- the minimum size of a vmalloc
   allocation is one page
 * Add a Context: section
 * Fix capitalisation
 * Reword the prohibition on calling from NMI context to avoid a double
   negative

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/vmalloc.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index be4724b916b3e7..8770260419af06 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2321,20 +2321,21 @@ static void __vfree(const void *addr)
 }
 
 /**
- * vfree - release memory allocated by vmalloc()
- * @addr:  memory base address
+ * vfree - Release memory allocated by vmalloc()
+ * @addr:  Memory base address
  *
- * Free the virtually continuous memory area starting at @addr, as
- * obtained from vmalloc(), vmalloc_32() or __vmalloc(). If @addr is
- * NULL, no operation is performed.
+ * Free the virtually continuous memory area starting at @addr, as obtained
+ * from one of the vmalloc() family of APIs.  This will usually also free the
+ * physical memory underlying the virtual allocation, but that memory is
+ * reference counted, so it will not be freed until the last user goes away.
  *
- * Must not be called in NMI context (strictly speaking, only if we don't
- * have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
- * conventions for vfree() arch-depenedent would be a really bad idea)
+ * If @addr is NULL, no operation is performed.
  *
+ * Context:
  * May sleep if called *not* from interrupt context.
- *
- * NOTE: assumes that the object at @addr has a size >= sizeof(llist_node)
+ * Must not be called in NMI context (strictly speaking, it could be
+ * if we have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
+ * conventions for vfree() arch-depenedent would be a really bad idea).
  */
 void vfree(const void *addr)
 {
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 01/11] mm: update the documentation for vfree
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

From: "Matthew Wilcox (Oracle)" <willy@infradead.org>

 * Document that you can call vfree() on an address returned from vmap()
 * Remove the note about the minimum size -- the minimum size of a vmalloc
   allocation is one page
 * Add a Context: section
 * Fix capitalisation
 * Reword the prohibition on calling from NMI context to avoid a double
   negative

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/vmalloc.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index be4724b916b3e7..8770260419af06 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2321,20 +2321,21 @@ static void __vfree(const void *addr)
 }
 
 /**
- * vfree - release memory allocated by vmalloc()
- * @addr:  memory base address
+ * vfree - Release memory allocated by vmalloc()
+ * @addr:  Memory base address
  *
- * Free the virtually continuous memory area starting at @addr, as
- * obtained from vmalloc(), vmalloc_32() or __vmalloc(). If @addr is
- * NULL, no operation is performed.
+ * Free the virtually continuous memory area starting at @addr, as obtained
+ * from one of the vmalloc() family of APIs.  This will usually also free the
+ * physical memory underlying the virtual allocation, but that memory is
+ * reference counted, so it will not be freed until the last user goes away.
  *
- * Must not be called in NMI context (strictly speaking, only if we don't
- * have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
- * conventions for vfree() arch-depenedent would be a really bad idea)
+ * If @addr is NULL, no operation is performed.
  *
+ * Context:
  * May sleep if called *not* from interrupt context.
- *
- * NOTE: assumes that the object at @addr has a size >= sizeof(llist_node)
+ * Must not be called in NMI context (strictly speaking, it could be
+ * if we have CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, but making the calling
+ * conventions for vfree() arch-depenedent would be a really bad idea).
  */
 void vfree(const void *addr)
 {
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 02/11] mm: add a VM_MAP_PUT_PAGES flag for vmap
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Add a flag so that vmap takes ownership of the passed in page array.
When vfree is called on such an allocation it will put one reference
on each page, and free the page array itself.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h | 1 +
 mm/vmalloc.c            | 9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 0221f852a7e1a3..b899681e3ff9f0 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -24,6 +24,7 @@ struct notifier_block;		/* in notifier.h */
 #define VM_UNINITIALIZED	0x00000020	/* vm_struct is not fully initialized */
 #define VM_NO_GUARD		0x00000040      /* don't add guard page */
 #define VM_KASAN		0x00000080      /* has allocated kasan shadow memory */
+#define VM_MAP_PUT_PAGES	0x00000100	/* put pages and free array in vfree */
 
 /*
  * VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC.
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8770260419af06..ffad65f052c3f9 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2377,8 +2377,11 @@ EXPORT_SYMBOL(vunmap);
  * @flags: vm_area->flags
  * @prot: page protection for the mapping
  *
- * Maps @count pages from @pages into contiguous kernel virtual
- * space.
+ * Maps @count pages from @pages into contiguous kernel virtual space.
+ * If @flags contains %VM_MAP_PUT_PAGES the ownership of the pages array itself
+ * (which must be kmalloc or vmalloc memory) and one reference per pages in it
+ * are transferred from the caller to vmap(), and will be freed / dropped when
+ * vfree() is called on the return value.
  *
  * Return: the address of the area or %NULL on failure
  */
@@ -2404,6 +2407,8 @@ void *vmap(struct page **pages, unsigned int count,
 		return NULL;
 	}
 
+	if (flags & VM_MAP_PUT_PAGES)
+		area->pages = pages;
 	return area->addr;
 }
 EXPORT_SYMBOL(vmap);
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 02/11] mm: add a VM_MAP_PUT_PAGES flag for vmap
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Add a flag so that vmap takes ownership of the passed in page array.
When vfree is called on such an allocation it will put one reference
on each page, and free the page array itself.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h | 1 +
 mm/vmalloc.c            | 9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 0221f852a7e1a3..b899681e3ff9f0 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -24,6 +24,7 @@ struct notifier_block;		/* in notifier.h */
 #define VM_UNINITIALIZED	0x00000020	/* vm_struct is not fully initialized */
 #define VM_NO_GUARD		0x00000040      /* don't add guard page */
 #define VM_KASAN		0x00000080      /* has allocated kasan shadow memory */
+#define VM_MAP_PUT_PAGES	0x00000100	/* put pages and free array in vfree */
 
 /*
  * VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC.
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8770260419af06..ffad65f052c3f9 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2377,8 +2377,11 @@ EXPORT_SYMBOL(vunmap);
  * @flags: vm_area->flags
  * @prot: page protection for the mapping
  *
- * Maps @count pages from @pages into contiguous kernel virtual
- * space.
+ * Maps @count pages from @pages into contiguous kernel virtual space.
+ * If @flags contains %VM_MAP_PUT_PAGES the ownership of the pages array itself
+ * (which must be kmalloc or vmalloc memory) and one reference per pages in it
+ * are transferred from the caller to vmap(), and will be freed / dropped when
+ * vfree() is called on the return value.
  *
  * Return: the address of the area or %NULL on failure
  */
@@ -2404,6 +2407,8 @@ void *vmap(struct page **pages, unsigned int count,
 		return NULL;
 	}
 
+	if (flags & VM_MAP_PUT_PAGES)
+		area->pages = pages;
 	return area->addr;
 }
 EXPORT_SYMBOL(vmap);
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 03/11] mm: add a vmap_pfn function
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h |  1 +
 mm/Kconfig              |  3 +++
 mm/vmalloc.c            | 45 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index b899681e3ff9f0..c77efeac242514 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -122,6 +122,7 @@ extern void vfree_atomic(const void *addr);
 
 extern void *vmap(struct page **pages, unsigned int count,
 			unsigned long flags, pgprot_t prot);
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot);
 extern void vunmap(const void *addr);
 
 extern int remap_vmalloc_range_partial(struct vm_area_struct *vma,
diff --git a/mm/Kconfig b/mm/Kconfig
index 6c974888f86f97..6fa7ba1199eb1e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -815,6 +815,9 @@ config DEVICE_PRIVATE
 	  memory; i.e., memory that is only accessible from the device (or
 	  group of devices). You likely also want to select HMM_MIRROR.
 
+config VMAP_PFN
+	bool
+
 config FRAME_VECTOR
 	bool
 
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ffad65f052c3f9..e2a2ded8d93478 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2413,6 +2413,51 @@ void *vmap(struct page **pages, unsigned int count,
 }
 EXPORT_SYMBOL(vmap);
 
+#ifdef CONFIG_VMAP_PFN
+struct vmap_pfn_data {
+	unsigned long	*pfns;
+	pgprot_t	prot;
+	unsigned int	idx;
+};
+
+static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
+{
+	struct vmap_pfn_data *data = private;
+
+	if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx])))
+		return -EINVAL;
+	*pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot));
+	return 0;
+}
+
+/**
+ * vmap_pfn - map an array of PFNs into virtually contiguous space
+ * @pfns: array of PFNs
+ * @count: number of pages to map
+ * @prot: page protection for the mapping
+ *
+ * Maps @count PFNs from @pfns into contiguous kernel virtual space and returns
+ * the start address of the mapping.
+ */
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot)
+{
+	struct vmap_pfn_data data = { .pfns = pfns, .prot = pgprot_nx(prot) };
+	struct vm_struct *area;
+
+	area = get_vm_area_caller(count * PAGE_SIZE, VM_IOREMAP,
+			__builtin_return_address(0));
+	if (!area)
+		return NULL;
+	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
+			count * PAGE_SIZE, vmap_pfn_apply, &data)) {
+		free_vm_area(area);
+		return NULL;
+	}
+	return area->addr;
+}
+EXPORT_SYMBOL_GPL(vmap_pfn);
+#endif /* CONFIG_VMAP_PFN */
+
 static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 				 pgprot_t prot, int node)
 {
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 03/11] mm: add a vmap_pfn function
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h |  1 +
 mm/Kconfig              |  3 +++
 mm/vmalloc.c            | 45 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index b899681e3ff9f0..c77efeac242514 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -122,6 +122,7 @@ extern void vfree_atomic(const void *addr);
 
 extern void *vmap(struct page **pages, unsigned int count,
 			unsigned long flags, pgprot_t prot);
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot);
 extern void vunmap(const void *addr);
 
 extern int remap_vmalloc_range_partial(struct vm_area_struct *vma,
diff --git a/mm/Kconfig b/mm/Kconfig
index 6c974888f86f97..6fa7ba1199eb1e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -815,6 +815,9 @@ config DEVICE_PRIVATE
 	  memory; i.e., memory that is only accessible from the device (or
 	  group of devices). You likely also want to select HMM_MIRROR.
 
+config VMAP_PFN
+	bool
+
 config FRAME_VECTOR
 	bool
 
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ffad65f052c3f9..e2a2ded8d93478 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2413,6 +2413,51 @@ void *vmap(struct page **pages, unsigned int count,
 }
 EXPORT_SYMBOL(vmap);
 
+#ifdef CONFIG_VMAP_PFN
+struct vmap_pfn_data {
+	unsigned long	*pfns;
+	pgprot_t	prot;
+	unsigned int	idx;
+};
+
+static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
+{
+	struct vmap_pfn_data *data = private;
+
+	if (WARN_ON_ONCE(pfn_valid(data->pfns[data->idx])))
+		return -EINVAL;
+	*pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot));
+	return 0;
+}
+
+/**
+ * vmap_pfn - map an array of PFNs into virtually contiguous space
+ * @pfns: array of PFNs
+ * @count: number of pages to map
+ * @prot: page protection for the mapping
+ *
+ * Maps @count PFNs from @pfns into contiguous kernel virtual space and returns
+ * the start address of the mapping.
+ */
+void *vmap_pfn(unsigned long *pfns, unsigned int count, pgprot_t prot)
+{
+	struct vmap_pfn_data data = { .pfns = pfns, .prot = pgprot_nx(prot) };
+	struct vm_struct *area;
+
+	area = get_vm_area_caller(count * PAGE_SIZE, VM_IOREMAP,
+			__builtin_return_address(0));
+	if (!area)
+		return NULL;
+	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
+			count * PAGE_SIZE, vmap_pfn_apply, &data)) {
+		free_vm_area(area);
+		return NULL;
+	}
+	return area->addr;
+}
+EXPORT_SYMBOL_GPL(vmap_pfn);
+#endif /* CONFIG_VMAP_PFN */
+
 static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 				 pgprot_t prot, int node)
 {
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 04/11] mm: allow a NULL fn callback in apply_to_page_range
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range.  To support callers
that only need the pre-faulting, make the callback optional.

Based on a patch from Minchan Kim <minchan@kernel.org>.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/memory.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 469af373ae76e1..a60136046d7fcc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2231,13 +2231,15 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 
 	arch_enter_lazy_mmu_mode();
 
-	do {
-		if (create || !pte_none(*pte)) {
-			err = fn(pte++, addr, data);
-			if (err)
-				break;
-		}
-	} while (addr += PAGE_SIZE, addr != end);
+	if (fn) {
+		do {
+			if (create || !pte_none(*pte)) {
+				err = fn(pte++, addr, data);
+				if (err)
+					break;
+			}
+		} while (addr += PAGE_SIZE, addr != end);
+	}
 	*mask |= PGTBL_PTE_MODIFIED;
 
 	arch_leave_lazy_mmu_mode();
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 04/11] mm: allow a NULL fn callback in apply_to_page_range
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range.  To support callers
that only need the pre-faulting, make the callback optional.

Based on a patch from Minchan Kim <minchan@kernel.org>.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/memory.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 469af373ae76e1..a60136046d7fcc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2231,13 +2231,15 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 
 	arch_enter_lazy_mmu_mode();
 
-	do {
-		if (create || !pte_none(*pte)) {
-			err = fn(pte++, addr, data);
-			if (err)
-				break;
-		}
-	} while (addr += PAGE_SIZE, addr != end);
+	if (fn) {
+		do {
+			if (create || !pte_none(*pte)) {
+				err = fn(pte++, addr, data);
+				if (err)
+					break;
+			}
+		} while (addr += PAGE_SIZE, addr != end);
+	}
 	*mask |= PGTBL_PTE_MODIFIED;
 
 	arch_leave_lazy_mmu_mode();
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 05/11] zsmalloc: switch from alloc_vm_area to get_vm_area
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Just manually pre-fault the PTEs using apply_to_page_range.

Co-developed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/zsmalloc.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c36fdff9a37131..918c7b019b3d78 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1122,10 +1122,16 @@ static inline int __zs_cpu_up(struct mapping_area *area)
 	 */
 	if (area->vm)
 		return 0;
-	area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
+	area->vm = get_vm_area(PAGE_SIZE * 2, 0);
 	if (!area->vm)
 		return -ENOMEM;
-	return 0;
+
+	/*
+	 * Populate ptes in advance to avoid pte allocation with GFP_KERNEL
+	 * in non-preemtible context of zs_map_object.
+	 */
+	return apply_to_page_range(&init_mm, (unsigned long)area->vm->addr,
+			PAGE_SIZE * 2, NULL, NULL);
 }
 
 static inline void __zs_cpu_down(struct mapping_area *area)
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 05/11] zsmalloc: switch from alloc_vm_area to get_vm_area
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Just manually pre-fault the PTEs using apply_to_page_range.

Co-developed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/zsmalloc.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c36fdff9a37131..918c7b019b3d78 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1122,10 +1122,16 @@ static inline int __zs_cpu_up(struct mapping_area *area)
 	 */
 	if (area->vm)
 		return 0;
-	area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
+	area->vm = get_vm_area(PAGE_SIZE * 2, 0);
 	if (!area->vm)
 		return -ENOMEM;
-	return 0;
+
+	/*
+	 * Populate ptes in advance to avoid pte allocation with GFP_KERNEL
+	 * in non-preemtible context of zs_map_object.
+	 */
+	return apply_to_page_range(&init_mm, (unsigned long)area->vm->addr,
+			PAGE_SIZE * 2, NULL, NULL);
 }
 
 static inline void __zs_cpu_down(struct mapping_area *area)
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup.  The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required).  Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++++++--------------------
 1 file changed, 18 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj)
 	return file;
 }
 
-static size_t shmem_npte(struct file *file)
-{
-	return file->f_mapping->host->i_size >> PAGE_SHIFT;
-}
-
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
-	unsigned long pfn;
-
-	vunmap(ptr);
-
-	for (pfn = 0; pfn < n_pte; pfn++) {
-		struct page *page;
-
-		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
-						   GFP_KERNEL);
-		if (!WARN_ON(IS_ERR(page))) {
-			put_page(page);
-			put_page(page);
-		}
-	}
-}
-
 void *shmem_pin_map(struct file *file)
 {
-	const size_t n_pte = shmem_npte(file);
-	pte_t *stack[32], **ptes, **mem;
-	struct vm_struct *area;
-	unsigned long pfn;
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
+	struct page **pages;
+	size_t n_pages, i;
+	void *vaddr;
 
-	area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
+	n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+	pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+	if (!pages)
 		return NULL;
-	}
 
-	ptes = mem;
-	for (pfn = 0; pfn < n_pte; pfn++) {
-		struct page *page;
-
-		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
-						   GFP_KERNEL);
-		if (IS_ERR(page))
+	for (i = 0; i < n_pages; i++) {
+		pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+						       GFP_KERNEL);
+		if (IS_ERR(pages[i]))
 			goto err_page;
-
-		**ptes++ = mk_pte(page,  PAGE_KERNEL);
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
+	vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
+	if (!vaddr)
+		goto err_page;
 	mapping_set_unevictable(file->f_mapping);
-	return area->addr;
-
+	return vaddr;
 err_page:
-	if (mem != stack)
-		kvfree(mem);
-
-	__shmem_unpin_map(file, area->addr, pfn);
+	while (--i >= 0)
+		put_page(pages[i]);
+	kvfree(pages);
 	return NULL;
 }
 
 void shmem_unpin_map(struct file *file, void *ptr)
 {
 	mapping_clear_unevictable(file->f_mapping);
-	__shmem_unpin_map(file, ptr, shmem_npte(file));
+	vfree(ptr);
 }
 
 static int __shmem_rw(struct file *file, loff_t off,
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup.  The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required).  Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++++++--------------------
 1 file changed, 18 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj)
 	return file;
 }
 
-static size_t shmem_npte(struct file *file)
-{
-	return file->f_mapping->host->i_size >> PAGE_SHIFT;
-}
-
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
-	unsigned long pfn;
-
-	vunmap(ptr);
-
-	for (pfn = 0; pfn < n_pte; pfn++) {
-		struct page *page;
-
-		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
-						   GFP_KERNEL);
-		if (!WARN_ON(IS_ERR(page))) {
-			put_page(page);
-			put_page(page);
-		}
-	}
-}
-
 void *shmem_pin_map(struct file *file)
 {
-	const size_t n_pte = shmem_npte(file);
-	pte_t *stack[32], **ptes, **mem;
-	struct vm_struct *area;
-	unsigned long pfn;
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
+	struct page **pages;
+	size_t n_pages, i;
+	void *vaddr;
 
-	area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
+	n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+	pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+	if (!pages)
 		return NULL;
-	}
 
-	ptes = mem;
-	for (pfn = 0; pfn < n_pte; pfn++) {
-		struct page *page;
-
-		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
-						   GFP_KERNEL);
-		if (IS_ERR(page))
+	for (i = 0; i < n_pages; i++) {
+		pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+						       GFP_KERNEL);
+		if (IS_ERR(pages[i]))
 			goto err_page;
-
-		**ptes++ = mk_pte(page,  PAGE_KERNEL);
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
+	vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
+	if (!vaddr)
+		goto err_page;
 	mapping_set_unevictable(file->f_mapping);
-	return area->addr;
-
+	return vaddr;
 err_page:
-	if (mem != stack)
-		kvfree(mem);
-
-	__shmem_unpin_map(file, area->addr, pfn);
+	while (--i >= 0)
+		put_page(pages[i]);
+	kvfree(pages);
 	return NULL;
 }
 
 void shmem_unpin_map(struct file *file, void *ptr)
 {
 	mapping_clear_unevictable(file->f_mapping);
-	__shmem_unpin_map(file, ptr, shmem_npte(file));
+	vfree(ptr);
 }
 
 static int __shmem_rw(struct file *file, loff_t off,
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj, void *ptr)
 {
 	if (is_vmalloc_addr(ptr))
 		vunmap(ptr);
-	else
-		kunmap(kmap_to_page(ptr));
 }
 
 struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * forever.
 		 *
 		 * So if the page is beyond the 32b boundary, make an explicit
-		 * vmap. On 64b, this check will be optimised away as we can
-		 * directly kmap any page on the system.
+		 * vmap.
 		 */
 		if (!PageHighMem(page))
-			return kmap(page);
+			return page_address(page);
 	}
 
 	mem = stack;
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj, void *ptr)
 {
 	if (is_vmalloc_addr(ptr))
 		vunmap(ptr);
-	else
-		kunmap(kmap_to_page(ptr));
 }
 
 struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * forever.
 		 *
 		 * So if the page is beyond the 32b boundary, make an explicit
-		 * vmap. On 64b, this check will be optimised away as we can
-		 * directly kmap any page on the system.
+		 * vmap.
 		 */
 		if (!PageHighMem(page))
-			return kmap(page);
+			return page_address(page);
 	}
 
 	mem = stack;
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

i915_gem_object_map implements fairly low-level vmap functionality in
a driver.  Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.

The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig              |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
 2 files changed, 59 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
 	select CRC32
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
+	select VMAP_PFN
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 	return err;
 }
 
-static inline pte_t iomap_pte(resource_size_t base,
-			      dma_addr_t offset,
-			      pgprot_t prot)
-{
-	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-				 enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
 {
-	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
-	struct sg_table *sgt = obj->mm.pages;
-	pte_t *stack[32], **mem;
-	struct vm_struct *area;
+	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+	struct page *stack[32], **pages = stack, *page;
+	struct sgt_iter iter;
 	pgprot_t pgprot;
+	void *vaddr;
 
-	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
-		return NULL;
-
-	if (GEM_WARN_ON(type == I915_MAP_WC &&
-			!static_cpu_has(X86_FEATURE_PAT)))
-		return NULL;
-
-	/* A single page can always be kmapped */
-	if (n_pte == 1 && type == I915_MAP_WB) {
-		struct page *page = sg_page(sgt->sgl);
-
+	switch (type) {
+	default:
+		MISSING_CASE(type);
+		fallthrough;	/* to use PAGE_KERNEL anyway */
+	case I915_MAP_WB:
 		/*
 		 * On 32b, highmem using a finite set of indirect PTE (i.e.
 		 * vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * So if the page is beyond the 32b boundary, make an explicit
 		 * vmap.
 		 */
-		if (!PageHighMem(page))
-			return page_address(page);
-	}
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		/* Too big for stack -- allocate temporary array instead */
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
-
-	area = alloc_vm_area(obj->base.size, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
-		return NULL;
-	}
-
-	switch (type) {
-	default:
-		MISSING_CASE(type);
-		fallthrough;	/* to use PAGE_KERNEL anyway */
-	case I915_MAP_WB:
+		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+			return page_address(sg_page(obj->mm.pages->sgl));
 		pgprot = PAGE_KERNEL;
 		break;
 	case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		break;
 	}
 
-	if (i915_gem_object_has_struct_page(obj)) {
-		struct sgt_iter iter;
-		struct page *page;
-		pte_t **ptes = mem;
+	if (n_pages > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+		if (!pages)
+			return NULL;
+	}
 
-		for_each_sgt_page(page, iter, sgt)
-			**ptes++ = mk_pte(page, pgprot);
-	} else {
-		resource_size_t iomap;
-		struct sgt_iter iter;
-		pte_t **ptes = mem;
-		dma_addr_t addr;
+	i = 0;
+	for_each_sgt_page(page, iter, obj->mm.pages)
+		pages[i++] = page;
+	vaddr = vmap(pages, n_pages, 0, pgprot);
+	if (pages != stack)
+		kvfree(pages);
+	return vaddr;
+}
 
-		iomap = obj->mm.region->iomap.base;
-		iomap -= obj->mm.region->region.start;
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
+{
+	resource_size_t iomap = obj->mm.region->iomap.base -
+		obj->mm.region->region.start;
+	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
+	unsigned long stack[32], *pfns = stack, i;
+	struct sgt_iter iter;
+	dma_addr_t addr;
+	void *vaddr;
+
+	if (type != I915_MAP_WC)
+		return NULL;
 
-		for_each_sgt_daddr(addr, iter, sgt)
-			**ptes++ = iomap_pte(iomap, addr, pgprot);
+	if (n_pfn > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
+		if (!pfns)
+			return NULL;
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
-	return area->addr;
+	for_each_sgt_daddr(addr, iter, obj->mm.pages)
+		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
+	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
+	if (pfns != stack)
+		kvfree(pfns);
+	return vaddr;
 }
 
 /* get, pin, and map the pages of the object into kernel space */
@@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
 	}
 
 	if (!ptr) {
-		ptr = i915_gem_object_map(obj, type);
+		if (GEM_WARN_ON(type == I915_MAP_WC &&
+				!static_cpu_has(X86_FEATURE_PAT)))
+			ptr = NULL;
+		else if (i915_gem_object_has_struct_page(obj))
+			ptr = i915_gem_object_map_page(obj, type);
+		else
+			ptr = i915_gem_object_map_pfn(obj, type);
 		if (!ptr) {
 			err = -ENOMEM;
 			goto err_unpin;
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

i915_gem_object_map implements fairly low-level vmap functionality in
a driver.  Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.

The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig              |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
 2 files changed, 59 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
 	select CRC32
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
+	select VMAP_PFN
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 	return err;
 }
 
-static inline pte_t iomap_pte(resource_size_t base,
-			      dma_addr_t offset,
-			      pgprot_t prot)
-{
-	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-				 enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
 {
-	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
-	struct sg_table *sgt = obj->mm.pages;
-	pte_t *stack[32], **mem;
-	struct vm_struct *area;
+	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+	struct page *stack[32], **pages = stack, *page;
+	struct sgt_iter iter;
 	pgprot_t pgprot;
+	void *vaddr;
 
-	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
-		return NULL;
-
-	if (GEM_WARN_ON(type == I915_MAP_WC &&
-			!static_cpu_has(X86_FEATURE_PAT)))
-		return NULL;
-
-	/* A single page can always be kmapped */
-	if (n_pte == 1 && type == I915_MAP_WB) {
-		struct page *page = sg_page(sgt->sgl);
-
+	switch (type) {
+	default:
+		MISSING_CASE(type);
+		fallthrough;	/* to use PAGE_KERNEL anyway */
+	case I915_MAP_WB:
 		/*
 		 * On 32b, highmem using a finite set of indirect PTE (i.e.
 		 * vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * So if the page is beyond the 32b boundary, make an explicit
 		 * vmap.
 		 */
-		if (!PageHighMem(page))
-			return page_address(page);
-	}
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		/* Too big for stack -- allocate temporary array instead */
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
-
-	area = alloc_vm_area(obj->base.size, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
-		return NULL;
-	}
-
-	switch (type) {
-	default:
-		MISSING_CASE(type);
-		fallthrough;	/* to use PAGE_KERNEL anyway */
-	case I915_MAP_WB:
+		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+			return page_address(sg_page(obj->mm.pages->sgl));
 		pgprot = PAGE_KERNEL;
 		break;
 	case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		break;
 	}
 
-	if (i915_gem_object_has_struct_page(obj)) {
-		struct sgt_iter iter;
-		struct page *page;
-		pte_t **ptes = mem;
+	if (n_pages > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+		if (!pages)
+			return NULL;
+	}
 
-		for_each_sgt_page(page, iter, sgt)
-			**ptes++ = mk_pte(page, pgprot);
-	} else {
-		resource_size_t iomap;
-		struct sgt_iter iter;
-		pte_t **ptes = mem;
-		dma_addr_t addr;
+	i = 0;
+	for_each_sgt_page(page, iter, obj->mm.pages)
+		pages[i++] = page;
+	vaddr = vmap(pages, n_pages, 0, pgprot);
+	if (pages != stack)
+		kvfree(pages);
+	return vaddr;
+}
 
-		iomap = obj->mm.region->iomap.base;
-		iomap -= obj->mm.region->region.start;
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
+{
+	resource_size_t iomap = obj->mm.region->iomap.base -
+		obj->mm.region->region.start;
+	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
+	unsigned long stack[32], *pfns = stack, i;
+	struct sgt_iter iter;
+	dma_addr_t addr;
+	void *vaddr;
+
+	if (type != I915_MAP_WC)
+		return NULL;
 
-		for_each_sgt_daddr(addr, iter, sgt)
-			**ptes++ = iomap_pte(iomap, addr, pgprot);
+	if (n_pfn > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
+		if (!pfns)
+			return NULL;
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
-	return area->addr;
+	for_each_sgt_daddr(addr, iter, obj->mm.pages)
+		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
+	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
+	if (pfns != stack)
+		kvfree(pfns);
+	return vaddr;
 }
 
 /* get, pin, and map the pages of the object into kernel space */
@@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
 	}
 
 	if (!ptr) {
-		ptr = i915_gem_object_map(obj, type);
+		if (GEM_WARN_ON(type == I915_MAP_WC &&
+				!static_cpu_has(X86_FEATURE_PAT)))
+			ptr = NULL;
+		else if (i915_gem_object_has_struct_page(obj))
+			ptr = i915_gem_object_map_page(obj, type);
+		else
+			ptr = i915_gem_object_map_pfn(obj, type);
 		if (!ptr) {
 			err = -ENOMEM;
 			goto err_unpin;
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/xen/xenbus/xenbus_client.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 2690318ad50f48..fd80e318b99cc7 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -73,16 +73,13 @@ struct map_ring_valloc {
 	struct xenbus_map_node *node;
 
 	/* Why do we need two arrays? See comment of __xenbus_map_ring */
-	union {
-		unsigned long addrs[XENBUS_MAX_RING_GRANTS];
-		pte_t *ptes[XENBUS_MAX_RING_GRANTS];
-	};
+	unsigned long addrs[XENBUS_MAX_RING_GRANTS];
 	phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
 
 	struct gnttab_map_grant_ref map[XENBUS_MAX_RING_GRANTS];
 	struct gnttab_unmap_grant_ref unmap[XENBUS_MAX_RING_GRANTS];
 
-	unsigned int idx;	/* HVM only. */
+	unsigned int idx;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
@@ -686,6 +683,14 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 #ifdef CONFIG_XEN_PV
+static int map_ring_apply(pte_t *pte, unsigned long addr, void *data)
+{
+	struct map_ring_valloc *info = data;
+
+	info->phys_addrs[info->idx++] = arbitrary_virt_to_machine(pte).maddr;
+	return 0;
+}
+
 static int xenbus_map_ring_pv(struct xenbus_device *dev,
 			      struct map_ring_valloc *info,
 			      grant_ref_t *gnt_refs,
@@ -694,18 +699,15 @@ static int xenbus_map_ring_pv(struct xenbus_device *dev,
 {
 	struct xenbus_map_node *node = info->node;
 	struct vm_struct *area;
-	int err = GNTST_okay;
-	int i;
-	bool leaked;
+	bool leaked = false;
+	int err = -ENOMEM;
 
-	area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, info->ptes);
+	area = get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_IOREMAP);
 	if (!area)
 		return -ENOMEM;
-
-	for (i = 0; i < nr_grefs; i++)
-		info->phys_addrs[i] =
-			arbitrary_virt_to_machine(info->ptes[i]).maddr;
-
+	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
+				XEN_PAGE_SIZE * nr_grefs, map_ring_apply, info))
+		goto failed;
 	err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
 				info, GNTMAP_host_map | GNTMAP_contains_pte,
 				&leaked);
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/xen/xenbus/xenbus_client.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 2690318ad50f48..fd80e318b99cc7 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -73,16 +73,13 @@ struct map_ring_valloc {
 	struct xenbus_map_node *node;
 
 	/* Why do we need two arrays? See comment of __xenbus_map_ring */
-	union {
-		unsigned long addrs[XENBUS_MAX_RING_GRANTS];
-		pte_t *ptes[XENBUS_MAX_RING_GRANTS];
-	};
+	unsigned long addrs[XENBUS_MAX_RING_GRANTS];
 	phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
 
 	struct gnttab_map_grant_ref map[XENBUS_MAX_RING_GRANTS];
 	struct gnttab_unmap_grant_ref unmap[XENBUS_MAX_RING_GRANTS];
 
-	unsigned int idx;	/* HVM only. */
+	unsigned int idx;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
@@ -686,6 +683,14 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 #ifdef CONFIG_XEN_PV
+static int map_ring_apply(pte_t *pte, unsigned long addr, void *data)
+{
+	struct map_ring_valloc *info = data;
+
+	info->phys_addrs[info->idx++] = arbitrary_virt_to_machine(pte).maddr;
+	return 0;
+}
+
 static int xenbus_map_ring_pv(struct xenbus_device *dev,
 			      struct map_ring_valloc *info,
 			      grant_ref_t *gnt_refs,
@@ -694,18 +699,15 @@ static int xenbus_map_ring_pv(struct xenbus_device *dev,
 {
 	struct xenbus_map_node *node = info->node;
 	struct vm_struct *area;
-	int err = GNTST_okay;
-	int i;
-	bool leaked;
+	bool leaked = false;
+	int err = -ENOMEM;
 
-	area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, info->ptes);
+	area = get_vm_area(XEN_PAGE_SIZE * nr_grefs, VM_IOREMAP);
 	if (!area)
 		return -ENOMEM;
-
-	for (i = 0; i < nr_grefs; i++)
-		info->phys_addrs[i] =
-			arbitrary_virt_to_machine(info->ptes[i]).maddr;
-
+	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
+				XEN_PAGE_SIZE * nr_grefs, map_ring_apply, info))
+		goto failed;
 	err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
 				info, GNTMAP_host_map | GNTMAP_contains_pte,
 				&leaked);
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/x86/xen/grant-table.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 4988e19598c8a5..1e681bf62561a0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -25,6 +25,7 @@
 static struct gnttab_vm_area {
 	struct vm_struct *area;
 	pte_t **ptes;
+	int idx;
 } gnttab_shared_vm_area, gnttab_status_vm_area;
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
@@ -90,19 +91,31 @@ void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 	}
 }
 
+static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
+{
+	struct gnttab_vm_area *area = data;
+
+	area->ptes[area->idx++] = pte;
+	return 0;
+}
+
 static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned nr_frames)
 {
 	area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL);
 	if (area->ptes == NULL)
 		return -ENOMEM;
-
-	area->area = alloc_vm_area(PAGE_SIZE * nr_frames, area->ptes);
-	if (area->area == NULL) {
-		kfree(area->ptes);
-		return -ENOMEM;
-	}
-
+	area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP);
+	if (!area->area)
+		goto out_free_ptes;
+	if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
+			PAGE_SIZE * nr_frames, gnttab_apply, area))
+		goto out_free_vm_area;
 	return 0;
+out_free_vm_area:
+	free_vm_area(area->area);
+out_free_ptes:
+	kfree(area->ptes);
+	return -ENOMEM;
 }
 
 static void arch_gnttab_vfree(struct gnttab_vm_area *area)
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/x86/xen/grant-table.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 4988e19598c8a5..1e681bf62561a0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -25,6 +25,7 @@
 static struct gnttab_vm_area {
 	struct vm_struct *area;
 	pte_t **ptes;
+	int idx;
 } gnttab_shared_vm_area, gnttab_status_vm_area;
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
@@ -90,19 +91,31 @@ void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 	}
 }
 
+static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
+{
+	struct gnttab_vm_area *area = data;
+
+	area->ptes[area->idx++] = pte;
+	return 0;
+}
+
 static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned nr_frames)
 {
 	area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL);
 	if (area->ptes == NULL)
 		return -ENOMEM;
-
-	area->area = alloc_vm_area(PAGE_SIZE * nr_frames, area->ptes);
-	if (area->area == NULL) {
-		kfree(area->ptes);
-		return -ENOMEM;
-	}
-
+	area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP);
+	if (!area->area)
+		goto out_free_ptes;
+	if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
+			PAGE_SIZE * nr_frames, gnttab_apply, area))
+		goto out_free_vm_area;
 	return 0;
+out_free_vm_area:
+	free_vm_area(area->area);
+out_free_ptes:
+	kfree(area->ptes);
+	return -ENOMEM;
 }
 
 static void arch_gnttab_vfree(struct gnttab_vm_area *area)
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [PATCH 11/11] mm: remove alloc_vm_area
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-24 13:58   ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

All users are gone now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h |  5 +----
 mm/nommu.c              |  7 ------
 mm/vmalloc.c            | 48 -----------------------------------------
 3 files changed, 1 insertion(+), 59 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index c77efeac242514..938eaf9517e266 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -169,6 +169,7 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long size,
 					unsigned long flags,
 					unsigned long start, unsigned long end,
 					const void *caller);
+void free_vm_area(struct vm_struct *area);
 extern struct vm_struct *remove_vm_area(const void *addr);
 extern struct vm_struct *find_vm_area(const void *addr);
 
@@ -204,10 +205,6 @@ static inline void set_vm_flush_reset_perms(void *addr)
 }
 #endif
 
-/* Allocate/destroy a 'vmalloc' VM area. */
-extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
-extern void free_vm_area(struct vm_struct *area);
-
 /* for /dev/kmem */
 extern long vread(char *buf, char *addr, unsigned long count);
 extern long vwrite(char *buf, char *addr, unsigned long count);
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af127..9272f30e4c4726 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -354,13 +354,6 @@ void vm_unmap_aliases(void)
 }
 EXPORT_SYMBOL_GPL(vm_unmap_aliases);
 
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
-	BUG();
-	return NULL;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
 void free_vm_area(struct vm_struct *area)
 {
 	BUG();
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e2a2ded8d93478..3bc5b832451ef2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3083,54 +3083,6 @@ int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
 }
 EXPORT_SYMBOL(remap_vmalloc_range);
 
-static int f(pte_t *pte, unsigned long addr, void *data)
-{
-	pte_t ***p = data;
-
-	if (p) {
-		*(*p) = pte;
-		(*p)++;
-	}
-	return 0;
-}
-
-/**
- * alloc_vm_area - allocate a range of kernel address space
- * @size:	   size of the area
- * @ptes:	   returns the PTEs for the address space
- *
- * Returns:	NULL on failure, vm_struct on success
- *
- * This function reserves a range of kernel address space, and
- * allocates pagetables to map that range.  No actual mappings
- * are created.
- *
- * If @ptes is non-NULL, pointers to the PTEs (in init_mm)
- * allocated for the VM area are returned.
- */
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
-	struct vm_struct *area;
-
-	area = get_vm_area_caller(size, VM_IOREMAP,
-				__builtin_return_address(0));
-	if (area == NULL)
-		return NULL;
-
-	/*
-	 * This ensures that page tables are constructed for this region
-	 * of kernel virtual address space and mapped into init_mm.
-	 */
-	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
-				size, f, ptes ? &ptes : NULL)) {
-		free_vm_area(area);
-		return NULL;
-	}
-
-	return area;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
 void free_vm_area(struct vm_struct *area)
 {
 	struct vm_struct *ret;
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 11/11] mm: remove alloc_vm_area
@ 2020-09-24 13:58   ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-24 13:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

All users are gone now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/vmalloc.h |  5 +----
 mm/nommu.c              |  7 ------
 mm/vmalloc.c            | 48 -----------------------------------------
 3 files changed, 1 insertion(+), 59 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index c77efeac242514..938eaf9517e266 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -169,6 +169,7 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long size,
 					unsigned long flags,
 					unsigned long start, unsigned long end,
 					const void *caller);
+void free_vm_area(struct vm_struct *area);
 extern struct vm_struct *remove_vm_area(const void *addr);
 extern struct vm_struct *find_vm_area(const void *addr);
 
@@ -204,10 +205,6 @@ static inline void set_vm_flush_reset_perms(void *addr)
 }
 #endif
 
-/* Allocate/destroy a 'vmalloc' VM area. */
-extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
-extern void free_vm_area(struct vm_struct *area);
-
 /* for /dev/kmem */
 extern long vread(char *buf, char *addr, unsigned long count);
 extern long vwrite(char *buf, char *addr, unsigned long count);
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af127..9272f30e4c4726 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -354,13 +354,6 @@ void vm_unmap_aliases(void)
 }
 EXPORT_SYMBOL_GPL(vm_unmap_aliases);
 
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
-	BUG();
-	return NULL;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
 void free_vm_area(struct vm_struct *area)
 {
 	BUG();
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e2a2ded8d93478..3bc5b832451ef2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3083,54 +3083,6 @@ int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
 }
 EXPORT_SYMBOL(remap_vmalloc_range);
 
-static int f(pte_t *pte, unsigned long addr, void *data)
-{
-	pte_t ***p = data;
-
-	if (p) {
-		*(*p) = pte;
-		(*p)++;
-	}
-	return 0;
-}
-
-/**
- * alloc_vm_area - allocate a range of kernel address space
- * @size:	   size of the area
- * @ptes:	   returns the PTEs for the address space
- *
- * Returns:	NULL on failure, vm_struct on success
- *
- * This function reserves a range of kernel address space, and
- * allocates pagetables to map that range.  No actual mappings
- * are created.
- *
- * If @ptes is non-NULL, pointers to the PTEs (in init_mm)
- * allocated for the VM area are returned.
- */
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
-	struct vm_struct *area;
-
-	area = get_vm_area_caller(size, VM_IOREMAP,
-				__builtin_return_address(0));
-	if (area == NULL)
-		return NULL;
-
-	/*
-	 * This ensures that page tables are constructed for this region
-	 * of kernel virtual address space and mapped into init_mm.
-	 */
-	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
-				size, f, ptes ? &ptes : NULL)) {
-		free_vm_area(area);
-		return NULL;
-	}
-
-	return area;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
 void free_vm_area(struct vm_struct *area)
 {
 	struct vm_struct *ret;
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] mm: update the documentation for vfree
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
                   ` (11 preceding siblings ...)
  (?)
@ 2020-09-24 15:09 ` Patchwork
  -1 siblings, 0 replies; 73+ messages in thread
From: Patchwork @ 2020-09-24 15:09 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx

== Series Details ==

Series: series starting with [01/11] mm: update the documentation for vfree
URL   : https://patchwork.freedesktop.org/series/82063/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5e88ddacdd34 mm: update the documentation for vfree
90f3c1ba13d1 mm: add a VM_MAP_PUT_PAGES flag for vmap
d41a24c9aa63 mm: add a vmap_pfn function
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: mm/vmalloc.c:2448:
+	area = get_vm_area_caller(count * PAGE_SIZE, VM_IOREMAP,
+			__builtin_return_address(0));

-:82: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#82: FILE: mm/vmalloc.c:2452:
+	if (apply_to_page_range(&init_mm, (unsigned long)area->addr,
+			count * PAGE_SIZE, vmap_pfn_apply, &data)) {

total: 0 errors, 0 warnings, 2 checks, 67 lines checked
5a2e6e88ce76 mm: allow a NULL fn callback in apply_to_page_range
140abd5e7d29 zsmalloc: switch from alloc_vm_area to get_vm_area
-:8: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not match 
#8: 
Co-developed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
total: 0 errors, 1 warnings, 0 checks, 18 lines checked
56b3f4b2f183 drm/i915: use vmap in shmem_pin_map
a037e6a84cf4 drm/i915: stop using kmap in i915_gem_object_map
1b6df0a418db drm/i915: use vmap in i915_gem_object_map
-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/gem/i915_gem_pages.c:237:
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)

-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/i915/gem/i915_gem_pages.c:293:
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)

total: 0 errors, 0 warnings, 2 checks, 166 lines checked
cad740b44a07 xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
15518d083ba6 x86/xen: open code alloc_vm_area in arch_gnttab_valloc
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: arch/x86/xen/grant-table.c:111:
+	if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
+			PAGE_SIZE * nr_frames, gnttab_apply, area))

total: 0 errors, 0 warnings, 1 checks, 45 lines checked
18c3303e9cc0 mm: remove alloc_vm_area


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] mm: update the documentation for vfree
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
                   ` (12 preceding siblings ...)
  (?)
@ 2020-09-24 15:34 ` Patchwork
  -1 siblings, 0 replies; 73+ messages in thread
From: Patchwork @ 2020-09-24 15:34 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 6325 bytes --]

== Series Details ==

Series: series starting with [01/11] mm: update the documentation for vfree
URL   : https://patchwork.freedesktop.org/series/82063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9049 -> Patchwork_18563
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/index.html

Known issues
------------

  Here are the changes found in Patchwork_18563 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_tiled_blits@basic:
    - fi-tgl-y:           [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@gem_tiled_blits@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@gem_tiled_blits@basic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
    - fi-icl-u2:          [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html

  
#### Possible fixes ####

  * igt@gem_flink_basic@double-flink:
    - fi-tgl-y:           [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@gem_flink_basic@double-flink.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@gem_flink_basic@double-flink.html

  * igt@i915_selftest@live@coherency:
    - fi-gdg-551:         [DMESG-FAIL][7] ([i915#1748]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-gdg-551/igt@i915_selftest@live@coherency.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-gdg-551/igt@i915_selftest@live@coherency.html

  * igt@kms_busy@basic@modeset:
    - {fi-tgl-dsi}:       [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1 similar issue
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
    - fi-tgl-y:           [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@kms_busy@basic@modeset.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@kms_busy@basic@modeset.html

  * igt@vgem_basic@unload:
    - fi-skl-guc:         [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-skl-guc/igt@vgem_basic@unload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-skl-guc/igt@vgem_basic@unload.html

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-tgl-y:           [DMESG-WARN][15] ([i915#1982] / [i915#2411]) -> [DMESG-WARN][16] ([i915#2411])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-tgl-y/igt@i915_pm_rpm@module-reload.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-tgl-y/igt@i915_pm_rpm@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
    - fi-kbl-x1275:       [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - fi-kbl-x1275:       [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (46 -> 40)
------------------------------

  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9049 -> Patchwork_18563

  CI-20190529: 20190529
  CI_DRM_9049: 6a36f5cbd72a6547eb096c2dcd130fc38861c649 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18563: 18c3303e9cc0a187606713181f8a87199d90d2d7 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

18c3303e9cc0 mm: remove alloc_vm_area
15518d083ba6 x86/xen: open code alloc_vm_area in arch_gnttab_valloc
cad740b44a07 xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
1b6df0a418db drm/i915: use vmap in i915_gem_object_map
a037e6a84cf4 drm/i915: stop using kmap in i915_gem_object_map
56b3f4b2f183 drm/i915: use vmap in shmem_pin_map
140abd5e7d29 zsmalloc: switch from alloc_vm_area to get_vm_area
5a2e6e88ce76 mm: allow a NULL fn callback in apply_to_page_range
d41a24c9aa63 mm: add a vmap_pfn function
90f3c1ba13d1 mm: add a VM_MAP_PUT_PAGES flag for vmap
5e88ddacdd34 mm: update the documentation for vfree

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/index.html

[-- Attachment #1.2: Type: text/html, Size: 7953 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] mm: update the documentation for vfree
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
                   ` (13 preceding siblings ...)
  (?)
@ 2020-09-24 20:44 ` Patchwork
  -1 siblings, 0 replies; 73+ messages in thread
From: Patchwork @ 2020-09-24 20:44 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 13277 bytes --]

== Series Details ==

Series: series starting with [01/11] mm: update the documentation for vfree
URL   : https://patchwork.freedesktop.org/series/82063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9049_full -> Patchwork_18563_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_18563_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@feature_discovery@psr2:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb2/igt@feature_discovery@psr2.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb7/igt@feature_discovery@psr2.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
    - shard-glk:          [PASS][3] -> [FAIL][4] ([i915#2389]) +2 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk4/igt@gem_exec_reloc@basic-many-active@rcs0.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk3/igt@gem_exec_reloc@basic-many-active@rcs0.html

  * igt@gem_exec_whisper@basic-fds-forked-all:
    - shard-glk:          [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk6/igt@gem_exec_whisper@basic-fds-forked-all.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk9/igt@gem_exec_whisper@basic-fds-forked-all.html

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         [PASS][7] -> [SKIP][8] ([i915#2190])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-tglb1/igt@gem_huc_copy@huc-copy.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-tglb6/igt@gem_huc_copy@huc-copy.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
    - shard-skl:          [PASS][9] -> [TIMEOUT][10] ([i915#1958] / [i915#2424])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl4/igt@gem_userptr_blits@sync-unmap-cycles.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl5/igt@gem_userptr_blits@sync-unmap-cycles.html

  * igt@i915_selftest@mock@requests:
    - shard-skl:          [PASS][11] -> [INCOMPLETE][12] ([i915#198] / [i915#2278])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl2/igt@i915_selftest@mock@requests.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl9/igt@i915_selftest@mock@requests.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - shard-skl:          [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +6 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl8/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl10/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@flip-vs-suspend@b-edp1:
    - shard-skl:          [PASS][15] -> [INCOMPLETE][16] ([i915#198])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl10/igt@kms_flip@flip-vs-suspend@b-edp1.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl1/igt@kms_flip@flip-vs-suspend@b-edp1.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render:
    - shard-tglb:         [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +2 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-tglb7/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-tglb1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render.html

  * igt@kms_psr@psr2_suspend:
    - shard-iclb:         [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb2/igt@kms_psr@psr2_suspend.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb7/igt@kms_psr@psr2_suspend.html

  
#### Possible fixes ####

  * igt@gem_exec_whisper@basic-queues-priority:
    - shard-glk:          [DMESG-WARN][21] ([i915#118] / [i915#95]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-glk5/igt@gem_exec_whisper@basic-queues-priority.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-glk4/igt@gem_exec_whisper@basic-queues-priority.html

  * igt@gen9_exec_parse@allowed-all:
    - shard-kbl:          [DMESG-WARN][23] ([i915#1436] / [i915#716]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-kbl1/igt@gen9_exec_parse@allowed-all.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-kbl7/igt@gen9_exec_parse@allowed-all.html

  * igt@i915_module_load@reload:
    - shard-apl:          [DMESG-WARN][25] ([i915#1635] / [i915#1982]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-apl3/igt@i915_module_load@reload.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-apl6/igt@i915_module_load@reload.html

  * igt@i915_selftest@mock@contexts:
    - shard-apl:          [INCOMPLETE][27] ([i915#1635] / [i915#2278]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-apl8/igt@i915_selftest@mock@contexts.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-apl7/igt@i915_selftest@mock@contexts.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-skl:          [INCOMPLETE][29] ([i915#198]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl10/igt@i915_suspend@fence-restore-untiled.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl2/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][31] ([i915#180]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-b-128x128-bottom-edge:
    - shard-kbl:          [DMESG-WARN][33] ([i915#1982]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-kbl6/igt@kms_cursor_edge_walk@pipe-b-128x128-bottom-edge.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-kbl2/igt@kms_cursor_edge_walk@pipe-b-128x128-bottom-edge.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
    - shard-skl:          [FAIL][35] ([i915#2122]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl10/igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-skl:          [FAIL][37] ([i915#1188]) -> [PASS][38] +1 similar issue
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl1/igt@kms_hdr@bpc-switch-suspend.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl3/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
    - shard-skl:          [DMESG-WARN][39] ([i915#1982]) -> [PASS][40] +8 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl6/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl8/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [SKIP][41] ([fdo#109642] / [fdo#111068]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb5/igt@kms_psr2_su@page_flip.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb2/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][43] ([fdo#109441]) -> [PASS][44] +3 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_vblank@pipe-d-wait-idle:
    - shard-tglb:         [DMESG-WARN][45] ([i915#1982]) -> [PASS][46] +2 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-tglb1/igt@kms_vblank@pipe-d-wait-idle.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-tglb6/igt@kms_vblank@pipe-d-wait-idle.html

  * igt@perf@polling-small-buf:
    - shard-iclb:         [FAIL][47] ([i915#1722]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb3/igt@perf@polling-small-buf.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb5/igt@perf@polling-small-buf.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc3co-vpb-simulation:
    - shard-iclb:         [SKIP][49] ([i915#588]) -> [SKIP][50] ([i915#658])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-iclb4/igt@i915_pm_dc@dc3co-vpb-simulation.html

  * igt@kms_content_protection@atomic:
    - shard-apl:          [FAIL][51] ([fdo#110321] / [fdo#110336] / [i915#1635]) -> [TIMEOUT][52] ([i915#1319] / [i915#1635] / [i915#1958])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-apl4/igt@kms_content_protection@atomic.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-apl1/igt@kms_content_protection@atomic.html

  * igt@kms_content_protection@lic:
    - shard-apl:          [TIMEOUT][53] ([i915#1319] / [i915#1635]) -> [TIMEOUT][54] ([i915#1319] / [i915#1635] / [i915#1958])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-apl6/igt@kms_content_protection@lic.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-apl3/igt@kms_content_protection@lic.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [DMESG-FAIL][55] ([fdo#108145] / [i915#1982]) -> [FAIL][56] ([fdo#108145] / [i915#265])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9049/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110321]: https://bugs.freedesktop.org/show_bug.cgi?id=110321
  [fdo#110336]: https://bugs.freedesktop.org/show_bug.cgi?id=110336
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2278]: https://gitlab.freedesktop.org/drm/intel/issues/2278
  [i915#2389]: https://gitlab.freedesktop.org/drm/intel/issues/2389
  [i915#2424]: https://gitlab.freedesktop.org/drm/intel/issues/2424
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * Linux: CI_DRM_9049 -> Patchwork_18563

  CI-20190529: 20190529
  CI_DRM_9049: 6a36f5cbd72a6547eb096c2dcd130fc38861c649 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18563: 18c3303e9cc0a187606713181f8a87199d90d2d7 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18563/index.html

[-- Attachment #1.2: Type: text/html, Size: 16062 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-24 23:42     ` boris.ostrovsky
  -1 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:42 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Peter Zijlstra, Juergen Gross, Stefano Stabellini, Jani Nikula,
	Joonas Lahtinen, Tvrtko Ursulin, Chris Wilson, Matthew Auld,
	Rodrigo Vivi, Minchan Kim, Matthew Wilcox, Nitin Gupta, x86,
	xen-devel, linux-kernel, intel-gfx, dri-devel, linux-mm


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


-boris


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
@ 2020-09-24 23:42     ` boris.ostrovsky
  0 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:42 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Tvrtko Ursulin, Stefano Stabellini,
	Matthew Wilcox, dri-devel, linux-mm, Peter Zijlstra,
	linux-kernel, intel-gfx, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, Rodrigo Vivi, xen-devel, Nitin Gupta


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


-boris

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
@ 2020-09-24 23:42     ` boris.ostrovsky
  0 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:42 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel, Nitin Gupta


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


-boris

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-24 23:43     ` boris.ostrovsky
  -1 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:43 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Peter Zijlstra, Juergen Gross, Stefano Stabellini, Jani Nikula,
	Joonas Lahtinen, Tvrtko Ursulin, Chris Wilson, Matthew Auld,
	Rodrigo Vivi, Minchan Kim, Matthew Wilcox, Nitin Gupta, x86,
	xen-devel, linux-kernel, intel-gfx, dri-devel, linux-mm


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>



^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
@ 2020-09-24 23:43     ` boris.ostrovsky
  0 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:43 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Tvrtko Ursulin, Stefano Stabellini,
	Matthew Wilcox, dri-devel, linux-mm, Peter Zijlstra,
	linux-kernel, intel-gfx, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, Rodrigo Vivi, xen-devel, Nitin Gupta


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
@ 2020-09-24 23:43     ` boris.ostrovsky
  0 siblings, 0 replies; 73+ messages in thread
From: boris.ostrovsky @ 2020-09-24 23:43 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel, Nitin Gupta


On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-25 13:01     ` Tvrtko Ursulin
  -1 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:01 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm


On 24/09/2020 14:58, Christoph Hellwig wrote:
> kmap for !PageHighmem is just a convoluted way to say page_address,
> and kunmap is a no-op in that case.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index d6eeefab3d018b..6550c0bc824ea2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj, void *ptr)
>   {
>   	if (is_vmalloc_addr(ptr))
>   		vunmap(ptr);
> -	else
> -		kunmap(kmap_to_page(ptr));
>   }
>   
>   struct sg_table *
> @@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * forever.
>   		 *
>   		 * So if the page is beyond the 32b boundary, make an explicit
> -		 * vmap. On 64b, this check will be optimised away as we can
> -		 * directly kmap any page on the system.
> +		 * vmap.
>   		 */
>   		if (!PageHighMem(page))
> -			return kmap(page);
> +			return page_address(page);
>   	}
>   
>   	mem = stack;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
@ 2020-09-25 13:01     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:01 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, Rodrigo Vivi, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> kmap for !PageHighmem is just a convoluted way to say page_address,
> and kunmap is a no-op in that case.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index d6eeefab3d018b..6550c0bc824ea2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj, void *ptr)
>   {
>   	if (is_vmalloc_addr(ptr))
>   		vunmap(ptr);
> -	else
> -		kunmap(kmap_to_page(ptr));
>   }
>   
>   struct sg_table *
> @@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * forever.
>   		 *
>   		 * So if the page is beyond the 32b boundary, make an explicit
> -		 * vmap. On 64b, this check will be optimised away as we can
> -		 * directly kmap any page on the system.
> +		 * vmap.
>   		 */
>   		if (!PageHighMem(page))
> -			return kmap(page);
> +			return page_address(page);
>   	}
>   
>   	mem = stack;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
@ 2020-09-25 13:01     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:01 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> kmap for !PageHighmem is just a convoluted way to say page_address,
> and kunmap is a no-op in that case.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index d6eeefab3d018b..6550c0bc824ea2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj, void *ptr)
>   {
>   	if (is_vmalloc_addr(ptr))
>   		vunmap(ptr);
> -	else
> -		kunmap(kmap_to_page(ptr));
>   }
>   
>   struct sg_table *
> @@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * forever.
>   		 *
>   		 * So if the page is beyond the 32b boundary, make an explicit
> -		 * vmap. On 64b, this check will be optimised away as we can
> -		 * directly kmap any page on the system.
> +		 * vmap.
>   		 */
>   		if (!PageHighMem(page))
> -			return kmap(page);
> +			return page_address(page);
>   	}
>   
>   	mem = stack;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-25 13:05     ` Tvrtko Ursulin
  -1 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:05 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm


On 24/09/2020 14:58, Christoph Hellwig wrote:
> shmem_pin_map somewhat awkwardly reimplements vmap using
> alloc_vm_area and manual pte setup.  The only practical difference
> is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
> seem to be required here (and could be added to vmap using a flag if
> actually required).  Switch to use vmap, and use vfree to free both the
> vmalloc mapping and the page array, as well as dropping the references
> to each page.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++++++--------------------
>   1 file changed, 18 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
> index 43c7acbdc79dea..f011ea42487e11 100644
> --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> @@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj)
>   	return file;
>   }
>   
> -static size_t shmem_npte(struct file *file)
> -{
> -	return file->f_mapping->host->i_size >> PAGE_SHIFT;
> -}
> -
> -static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
> -{
> -	unsigned long pfn;
> -
> -	vunmap(ptr);
> -
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (!WARN_ON(IS_ERR(page))) {
> -			put_page(page);
> -			put_page(page);
> -		}
> -	}
> -}
> -
>   void *shmem_pin_map(struct file *file)
>   {
> -	const size_t n_pte = shmem_npte(file);
> -	pte_t *stack[32], **ptes, **mem;
> -	struct vm_struct *area;
> -	unsigned long pfn;
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> +	struct page **pages;
> +	size_t n_pages, i;
> +	void *vaddr;
>   
> -	area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> +	n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
> +	pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +	if (!pages)
>   		return NULL;
> -	}
>   
> -	ptes = mem;
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (IS_ERR(page))
> +	for (i = 0; i < n_pages; i++) {
> +		pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
> +						       GFP_KERNEL);
> +		if (IS_ERR(pages[i]))
>   			goto err_page;
> -
> -		**ptes++ = mk_pte(page,  PAGE_KERNEL);
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> +	vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
> +	if (!vaddr)
> +		goto err_page;
>   	mapping_set_unevictable(file->f_mapping);
> -	return area->addr;
> -
> +	return vaddr;
>   err_page:
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	__shmem_unpin_map(file, area->addr, pfn);
> +	while (--i >= 0)
> +		put_page(pages[i]);
> +	kvfree(pages);
>   	return NULL;
>   }
>   
>   void shmem_unpin_map(struct file *file, void *ptr)
>   {
>   	mapping_clear_unevictable(file->f_mapping);
> -	__shmem_unpin_map(file, ptr, shmem_npte(file));
> +	vfree(ptr);
>   }
>   
>   static int __shmem_rw(struct file *file, loff_t off,
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
@ 2020-09-25 13:05     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:05 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, Rodrigo Vivi, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> shmem_pin_map somewhat awkwardly reimplements vmap using
> alloc_vm_area and manual pte setup.  The only practical difference
> is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
> seem to be required here (and could be added to vmap using a flag if
> actually required).  Switch to use vmap, and use vfree to free both the
> vmalloc mapping and the page array, as well as dropping the references
> to each page.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++++++--------------------
>   1 file changed, 18 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
> index 43c7acbdc79dea..f011ea42487e11 100644
> --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> @@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj)
>   	return file;
>   }
>   
> -static size_t shmem_npte(struct file *file)
> -{
> -	return file->f_mapping->host->i_size >> PAGE_SHIFT;
> -}
> -
> -static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
> -{
> -	unsigned long pfn;
> -
> -	vunmap(ptr);
> -
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (!WARN_ON(IS_ERR(page))) {
> -			put_page(page);
> -			put_page(page);
> -		}
> -	}
> -}
> -
>   void *shmem_pin_map(struct file *file)
>   {
> -	const size_t n_pte = shmem_npte(file);
> -	pte_t *stack[32], **ptes, **mem;
> -	struct vm_struct *area;
> -	unsigned long pfn;
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> +	struct page **pages;
> +	size_t n_pages, i;
> +	void *vaddr;
>   
> -	area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> +	n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
> +	pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +	if (!pages)
>   		return NULL;
> -	}
>   
> -	ptes = mem;
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (IS_ERR(page))
> +	for (i = 0; i < n_pages; i++) {
> +		pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
> +						       GFP_KERNEL);
> +		if (IS_ERR(pages[i]))
>   			goto err_page;
> -
> -		**ptes++ = mk_pte(page,  PAGE_KERNEL);
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> +	vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
> +	if (!vaddr)
> +		goto err_page;
>   	mapping_set_unevictable(file->f_mapping);
> -	return area->addr;
> -
> +	return vaddr;
>   err_page:
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	__shmem_unpin_map(file, area->addr, pfn);
> +	while (--i >= 0)
> +		put_page(pages[i]);
> +	kvfree(pages);
>   	return NULL;
>   }
>   
>   void shmem_unpin_map(struct file *file, void *ptr)
>   {
>   	mapping_clear_unevictable(file->f_mapping);
> -	__shmem_unpin_map(file, ptr, shmem_npte(file));
> +	vfree(ptr);
>   }
>   
>   static int __shmem_rw(struct file *file, loff_t off,
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
@ 2020-09-25 13:05     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:05 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> shmem_pin_map somewhat awkwardly reimplements vmap using
> alloc_vm_area and manual pte setup.  The only practical difference
> is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
> seem to be required here (and could be added to vmap using a flag if
> actually required).  Switch to use vmap, and use vfree to free both the
> vmalloc mapping and the page array, as well as dropping the references
> to each page.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++++++--------------------
>   1 file changed, 18 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
> index 43c7acbdc79dea..f011ea42487e11 100644
> --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> @@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj)
>   	return file;
>   }
>   
> -static size_t shmem_npte(struct file *file)
> -{
> -	return file->f_mapping->host->i_size >> PAGE_SHIFT;
> -}
> -
> -static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
> -{
> -	unsigned long pfn;
> -
> -	vunmap(ptr);
> -
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (!WARN_ON(IS_ERR(page))) {
> -			put_page(page);
> -			put_page(page);
> -		}
> -	}
> -}
> -
>   void *shmem_pin_map(struct file *file)
>   {
> -	const size_t n_pte = shmem_npte(file);
> -	pte_t *stack[32], **ptes, **mem;
> -	struct vm_struct *area;
> -	unsigned long pfn;
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> +	struct page **pages;
> +	size_t n_pages, i;
> +	void *vaddr;
>   
> -	area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> +	n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
> +	pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +	if (!pages)
>   		return NULL;
> -	}
>   
> -	ptes = mem;
> -	for (pfn = 0; pfn < n_pte; pfn++) {
> -		struct page *page;
> -
> -		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> -						   GFP_KERNEL);
> -		if (IS_ERR(page))
> +	for (i = 0; i < n_pages; i++) {
> +		pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
> +						       GFP_KERNEL);
> +		if (IS_ERR(pages[i]))
>   			goto err_page;
> -
> -		**ptes++ = mk_pte(page,  PAGE_KERNEL);
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> +	vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
> +	if (!vaddr)
> +		goto err_page;
>   	mapping_set_unevictable(file->f_mapping);
> -	return area->addr;
> -
> +	return vaddr;
>   err_page:
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	__shmem_unpin_map(file, area->addr, pfn);
> +	while (--i >= 0)
> +		put_page(pages[i]);
> +	kvfree(pages);
>   	return NULL;
>   }
>   
>   void shmem_unpin_map(struct file *file, void *ptr)
>   {
>   	mapping_clear_unevictable(file->f_mapping);
> -	__shmem_unpin_map(file, ptr, shmem_npte(file));
> +	vfree(ptr);
>   }
>   
>   static int __shmem_rw(struct file *file, loff_t off,
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-25 13:11     ` Tvrtko Ursulin
  -1 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:11 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm


On 24/09/2020 14:58, Christoph Hellwig wrote:
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
> 
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/Kconfig              |   1 +
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>   2 files changed, 59 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>   	select CRC32
>   	select SND_HDA_I915 if SND_HDA_CORE
>   	select CEC_CORE if CEC_NOTIFIER
> +	select VMAP_PFN
>   	help
>   	  Choose this option if you have a system that has "Intel Graphics
>   	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>   	return err;
>   }
>   
> -static inline pte_t iomap_pte(resource_size_t base,
> -			      dma_addr_t offset,
> -			      pgprot_t prot)
> -{
> -	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>   /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -				 enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
>   {
> -	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -	struct sg_table *sgt = obj->mm.pages;
> -	pte_t *stack[32], **mem;
> -	struct vm_struct *area;
> +	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +	struct page *stack[32], **pages = stack, *page;
> +	struct sgt_iter iter;
>   	pgprot_t pgprot;
> +	void *vaddr;
>   
> -	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -		return NULL;
> -
> -	if (GEM_WARN_ON(type == I915_MAP_WC &&
> -			!static_cpu_has(X86_FEATURE_PAT)))
> -		return NULL;
> -
> -	/* A single page can always be kmapped */
> -	if (n_pte == 1 && type == I915_MAP_WB) {
> -		struct page *page = sg_page(sgt->sgl);
> -
> +	switch (type) {
> +	default:
> +		MISSING_CASE(type);
> +		fallthrough;	/* to use PAGE_KERNEL anyway */
> +	case I915_MAP_WB:
>   		/*
>   		 * On 32b, highmem using a finite set of indirect PTE (i.e.
>   		 * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * So if the page is beyond the 32b boundary, make an explicit
>   		 * vmap.
>   		 */
> -		if (!PageHighMem(page))
> -			return page_address(page);
> -	}
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		/* Too big for stack -- allocate temporary array instead */
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> -
> -	area = alloc_vm_area(obj->base.size, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> -		return NULL;
> -	}
> -
> -	switch (type) {
> -	default:
> -		MISSING_CASE(type);
> -		fallthrough;	/* to use PAGE_KERNEL anyway */
> -	case I915_MAP_WB:
> +		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +			return page_address(sg_page(obj->mm.pages->sgl));
>   		pgprot = PAGE_KERNEL;
>   		break;
>   	case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		break;
>   	}
>   
> -	if (i915_gem_object_has_struct_page(obj)) {
> -		struct sgt_iter iter;
> -		struct page *page;
> -		pte_t **ptes = mem;
> +	if (n_pages > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +		if (!pages)
> +			return NULL;
> +	}
>   
> -		for_each_sgt_page(page, iter, sgt)
> -			**ptes++ = mk_pte(page, pgprot);
> -	} else {
> -		resource_size_t iomap;
> -		struct sgt_iter iter;
> -		pte_t **ptes = mem;
> -		dma_addr_t addr;
> +	i = 0;
> +	for_each_sgt_page(page, iter, obj->mm.pages)
> +		pages[i++] = page;
> +	vaddr = vmap(pages, n_pages, 0, pgprot);
> +	if (pages != stack)
> +		kvfree(pages);
> +	return vaddr;
> +}
>   
> -		iomap = obj->mm.region->iomap.base;
> -		iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
> +{
> +	resource_size_t iomap = obj->mm.region->iomap.base -
> +		obj->mm.region->region.start;
> +	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +	unsigned long stack[32], *pfns = stack, i;
> +	struct sgt_iter iter;
> +	dma_addr_t addr;
> +	void *vaddr;
> +
> +	if (type != I915_MAP_WC)
> +		return NULL;
>   
> -		for_each_sgt_daddr(addr, iter, sgt)
> -			**ptes++ = iomap_pte(iomap, addr, pgprot);
> +	if (n_pfn > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +		if (!pfns)
> +			return NULL;
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	return area->addr;
> +	for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
> +	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +	if (pfns != stack)
> +		kvfree(pfns);
> +	return vaddr;
>   }
>   
>   /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>   	}
>   
>   	if (!ptr) {
> -		ptr = i915_gem_object_map(obj, type);
> +		if (GEM_WARN_ON(type == I915_MAP_WC &&
> +				!static_cpu_has(X86_FEATURE_PAT)))
> +			ptr = NULL;
> +		else if (i915_gem_object_has_struct_page(obj))
> +			ptr = i915_gem_object_map_page(obj, type);
> +		else
> +			ptr = i915_gem_object_map_pfn(obj, type);
>   		if (!ptr) {
>   			err = -ENOMEM;
>   			goto err_unpin;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 13:11     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:11 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, Rodrigo Vivi, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
> 
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/Kconfig              |   1 +
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>   2 files changed, 59 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>   	select CRC32
>   	select SND_HDA_I915 if SND_HDA_CORE
>   	select CEC_CORE if CEC_NOTIFIER
> +	select VMAP_PFN
>   	help
>   	  Choose this option if you have a system that has "Intel Graphics
>   	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>   	return err;
>   }
>   
> -static inline pte_t iomap_pte(resource_size_t base,
> -			      dma_addr_t offset,
> -			      pgprot_t prot)
> -{
> -	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>   /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -				 enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
>   {
> -	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -	struct sg_table *sgt = obj->mm.pages;
> -	pte_t *stack[32], **mem;
> -	struct vm_struct *area;
> +	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +	struct page *stack[32], **pages = stack, *page;
> +	struct sgt_iter iter;
>   	pgprot_t pgprot;
> +	void *vaddr;
>   
> -	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -		return NULL;
> -
> -	if (GEM_WARN_ON(type == I915_MAP_WC &&
> -			!static_cpu_has(X86_FEATURE_PAT)))
> -		return NULL;
> -
> -	/* A single page can always be kmapped */
> -	if (n_pte == 1 && type == I915_MAP_WB) {
> -		struct page *page = sg_page(sgt->sgl);
> -
> +	switch (type) {
> +	default:
> +		MISSING_CASE(type);
> +		fallthrough;	/* to use PAGE_KERNEL anyway */
> +	case I915_MAP_WB:
>   		/*
>   		 * On 32b, highmem using a finite set of indirect PTE (i.e.
>   		 * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * So if the page is beyond the 32b boundary, make an explicit
>   		 * vmap.
>   		 */
> -		if (!PageHighMem(page))
> -			return page_address(page);
> -	}
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		/* Too big for stack -- allocate temporary array instead */
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> -
> -	area = alloc_vm_area(obj->base.size, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> -		return NULL;
> -	}
> -
> -	switch (type) {
> -	default:
> -		MISSING_CASE(type);
> -		fallthrough;	/* to use PAGE_KERNEL anyway */
> -	case I915_MAP_WB:
> +		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +			return page_address(sg_page(obj->mm.pages->sgl));
>   		pgprot = PAGE_KERNEL;
>   		break;
>   	case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		break;
>   	}
>   
> -	if (i915_gem_object_has_struct_page(obj)) {
> -		struct sgt_iter iter;
> -		struct page *page;
> -		pte_t **ptes = mem;
> +	if (n_pages > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +		if (!pages)
> +			return NULL;
> +	}
>   
> -		for_each_sgt_page(page, iter, sgt)
> -			**ptes++ = mk_pte(page, pgprot);
> -	} else {
> -		resource_size_t iomap;
> -		struct sgt_iter iter;
> -		pte_t **ptes = mem;
> -		dma_addr_t addr;
> +	i = 0;
> +	for_each_sgt_page(page, iter, obj->mm.pages)
> +		pages[i++] = page;
> +	vaddr = vmap(pages, n_pages, 0, pgprot);
> +	if (pages != stack)
> +		kvfree(pages);
> +	return vaddr;
> +}
>   
> -		iomap = obj->mm.region->iomap.base;
> -		iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
> +{
> +	resource_size_t iomap = obj->mm.region->iomap.base -
> +		obj->mm.region->region.start;
> +	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +	unsigned long stack[32], *pfns = stack, i;
> +	struct sgt_iter iter;
> +	dma_addr_t addr;
> +	void *vaddr;
> +
> +	if (type != I915_MAP_WC)
> +		return NULL;
>   
> -		for_each_sgt_daddr(addr, iter, sgt)
> -			**ptes++ = iomap_pte(iomap, addr, pgprot);
> +	if (n_pfn > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +		if (!pfns)
> +			return NULL;
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	return area->addr;
> +	for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
> +	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +	if (pfns != stack)
> +		kvfree(pfns);
> +	return vaddr;
>   }
>   
>   /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>   	}
>   
>   	if (!ptr) {
> -		ptr = i915_gem_object_map(obj, type);
> +		if (GEM_WARN_ON(type == I915_MAP_WC &&
> +				!static_cpu_has(X86_FEATURE_PAT)))
> +			ptr = NULL;
> +		else if (i915_gem_object_has_struct_page(obj))
> +			ptr = i915_gem_object_map_page(obj, type);
> +		else
> +			ptr = i915_gem_object_map_pfn(obj, type);
>   		if (!ptr) {
>   			err = -ENOMEM;
>   			goto err_unpin;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 13:11     ` Tvrtko Ursulin
  0 siblings, 0 replies; 73+ messages in thread
From: Tvrtko Ursulin @ 2020-09-25 13:11 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta


On 24/09/2020 14:58, Christoph Hellwig wrote:
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
> 
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/gpu/drm/i915/Kconfig              |   1 +
>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>   2 files changed, 59 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>   	select CRC32
>   	select SND_HDA_I915 if SND_HDA_CORE
>   	select CEC_CORE if CEC_NOTIFIER
> +	select VMAP_PFN
>   	help
>   	  Choose this option if you have a system that has "Intel Graphics
>   	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>   	return err;
>   }
>   
> -static inline pte_t iomap_pte(resource_size_t base,
> -			      dma_addr_t offset,
> -			      pgprot_t prot)
> -{
> -	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>   /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -				 enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
>   {
> -	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -	struct sg_table *sgt = obj->mm.pages;
> -	pte_t *stack[32], **mem;
> -	struct vm_struct *area;
> +	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +	struct page *stack[32], **pages = stack, *page;
> +	struct sgt_iter iter;
>   	pgprot_t pgprot;
> +	void *vaddr;
>   
> -	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -		return NULL;
> -
> -	if (GEM_WARN_ON(type == I915_MAP_WC &&
> -			!static_cpu_has(X86_FEATURE_PAT)))
> -		return NULL;
> -
> -	/* A single page can always be kmapped */
> -	if (n_pte == 1 && type == I915_MAP_WB) {
> -		struct page *page = sg_page(sgt->sgl);
> -
> +	switch (type) {
> +	default:
> +		MISSING_CASE(type);
> +		fallthrough;	/* to use PAGE_KERNEL anyway */
> +	case I915_MAP_WB:
>   		/*
>   		 * On 32b, highmem using a finite set of indirect PTE (i.e.
>   		 * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		 * So if the page is beyond the 32b boundary, make an explicit
>   		 * vmap.
>   		 */
> -		if (!PageHighMem(page))
> -			return page_address(page);
> -	}
> -
> -	mem = stack;
> -	if (n_pte > ARRAY_SIZE(stack)) {
> -		/* Too big for stack -- allocate temporary array instead */
> -		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -		if (!mem)
> -			return NULL;
> -	}
> -
> -	area = alloc_vm_area(obj->base.size, mem);
> -	if (!area) {
> -		if (mem != stack)
> -			kvfree(mem);
> -		return NULL;
> -	}
> -
> -	switch (type) {
> -	default:
> -		MISSING_CASE(type);
> -		fallthrough;	/* to use PAGE_KERNEL anyway */
> -	case I915_MAP_WB:
> +		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +			return page_address(sg_page(obj->mm.pages->sgl));
>   		pgprot = PAGE_KERNEL;
>   		break;
>   	case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>   		break;
>   	}
>   
> -	if (i915_gem_object_has_struct_page(obj)) {
> -		struct sgt_iter iter;
> -		struct page *page;
> -		pte_t **ptes = mem;
> +	if (n_pages > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +		if (!pages)
> +			return NULL;
> +	}
>   
> -		for_each_sgt_page(page, iter, sgt)
> -			**ptes++ = mk_pte(page, pgprot);
> -	} else {
> -		resource_size_t iomap;
> -		struct sgt_iter iter;
> -		pte_t **ptes = mem;
> -		dma_addr_t addr;
> +	i = 0;
> +	for_each_sgt_page(page, iter, obj->mm.pages)
> +		pages[i++] = page;
> +	vaddr = vmap(pages, n_pages, 0, pgprot);
> +	if (pages != stack)
> +		kvfree(pages);
> +	return vaddr;
> +}
>   
> -		iomap = obj->mm.region->iomap.base;
> -		iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +		enum i915_map_type type)
> +{
> +	resource_size_t iomap = obj->mm.region->iomap.base -
> +		obj->mm.region->region.start;
> +	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +	unsigned long stack[32], *pfns = stack, i;
> +	struct sgt_iter iter;
> +	dma_addr_t addr;
> +	void *vaddr;
> +
> +	if (type != I915_MAP_WC)
> +		return NULL;
>   
> -		for_each_sgt_daddr(addr, iter, sgt)
> -			**ptes++ = iomap_pte(iomap, addr, pgprot);
> +	if (n_pfn > ARRAY_SIZE(stack)) {
> +		/* Too big for stack -- allocate temporary array instead */
> +		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +		if (!pfns)
> +			return NULL;
>   	}
>   
> -	if (mem != stack)
> -		kvfree(mem);
> -
> -	return area->addr;
> +	for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
> +	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +	if (pfns != stack)
> +		kvfree(pfns);
> +	return vaddr;
>   }
>   
>   /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>   	}
>   
>   	if (!ptr) {
> -		ptr = i915_gem_object_map(obj, type);
> +		if (GEM_WARN_ON(type == I915_MAP_WC &&
> +				!static_cpu_has(X86_FEATURE_PAT)))
> +			ptr = NULL;
> +		else if (i915_gem_object_has_struct_page(obj))
> +			ptr = i915_gem_object_map_page(obj, type);
> +		else
> +			ptr = i915_gem_object_map_pfn(obj, type);
>   		if (!ptr) {
>   			err = -ENOMEM;
>   			goto err_unpin;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
                       ` (2 preceding siblings ...)
  (?)
@ 2020-09-25 14:08     ` Matthew Auld
  -1 siblings, 0 replies; 73+ messages in thread
From: Matthew Auld @ 2020-09-25 14:08 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Juergen Gross, Stefano Stabellini, Matthew Wilcox,
	ML dri-devel, linux-mm, Peter Zijlstra, kernel list,
	Intel Graphics Development, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, xen-devel, Boris Ostrovsky, Nitin Gupta

On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig <hch@lst.de> wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig              |   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>  2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>         select CRC32
>         select SND_HDA_I915 if SND_HDA_CORE
>         select CEC_CORE if CEC_NOTIFIER
> +       select VMAP_PFN
>         help
>           Choose this option if you have a system that has "Intel Graphics
>           Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>         return err;
>  }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> -                             dma_addr_t offset,
> -                             pgprot_t prot)
> -{
> -       return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>  /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -                                enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
>  {
> -       unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -       struct sg_table *sgt = obj->mm.pages;
> -       pte_t *stack[32], **mem;
> -       struct vm_struct *area;
> +       unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +       struct page *stack[32], **pages = stack, *page;
> +       struct sgt_iter iter;
>         pgprot_t pgprot;
> +       void *vaddr;
>
> -       if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -               return NULL;
> -
> -       if (GEM_WARN_ON(type == I915_MAP_WC &&
> -                       !static_cpu_has(X86_FEATURE_PAT)))
> -               return NULL;
> -
> -       /* A single page can always be kmapped */
> -       if (n_pte == 1 && type == I915_MAP_WB) {
> -               struct page *page = sg_page(sgt->sgl);
> -
> +       switch (type) {
> +       default:
> +               MISSING_CASE(type);
> +               fallthrough;    /* to use PAGE_KERNEL anyway */
> +       case I915_MAP_WB:
>                 /*
>                  * On 32b, highmem using a finite set of indirect PTE (i.e.
>                  * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                  * So if the page is beyond the 32b boundary, make an explicit
>                  * vmap.
>                  */
> -               if (!PageHighMem(page))
> -                       return page_address(page);
> -       }
> -
> -       mem = stack;
> -       if (n_pte > ARRAY_SIZE(stack)) {
> -               /* Too big for stack -- allocate temporary array instead */
> -               mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -               if (!mem)
> -                       return NULL;
> -       }
> -
> -       area = alloc_vm_area(obj->base.size, mem);
> -       if (!area) {
> -               if (mem != stack)
> -                       kvfree(mem);
> -               return NULL;
> -       }
> -
> -       switch (type) {
> -       default:
> -               MISSING_CASE(type);
> -               fallthrough;    /* to use PAGE_KERNEL anyway */
> -       case I915_MAP_WB:
> +               if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +                       return page_address(sg_page(obj->mm.pages->sgl));
>                 pgprot = PAGE_KERNEL;
>                 break;
>         case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                 break;
>         }
>
> -       if (i915_gem_object_has_struct_page(obj)) {
> -               struct sgt_iter iter;
> -               struct page *page;
> -               pte_t **ptes = mem;
> +       if (n_pages > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +               if (!pages)
> +                       return NULL;
> +       }
>
> -               for_each_sgt_page(page, iter, sgt)
> -                       **ptes++ = mk_pte(page, pgprot);
> -       } else {
> -               resource_size_t iomap;
> -               struct sgt_iter iter;
> -               pte_t **ptes = mem;
> -               dma_addr_t addr;
> +       i = 0;
> +       for_each_sgt_page(page, iter, obj->mm.pages)
> +               pages[i++] = page;
> +       vaddr = vmap(pages, n_pages, 0, pgprot);
> +       if (pages != stack)
> +               kvfree(pages);
> +       return vaddr;
> +}
>
> -               iomap = obj->mm.region->iomap.base;
> -               iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
> +{
> +       resource_size_t iomap = obj->mm.region->iomap.base -
> +               obj->mm.region->region.start;
> +       unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +       unsigned long stack[32], *pfns = stack, i;
> +       struct sgt_iter iter;
> +       dma_addr_t addr;
> +       void *vaddr;
> +
> +       if (type != I915_MAP_WC)
> +               return NULL;
>
> -               for_each_sgt_daddr(addr, iter, sgt)
> -                       **ptes++ = iomap_pte(iomap, addr, pgprot);
> +       if (n_pfn > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +               if (!pfns)
> +                       return NULL;
>         }
>
> -       if (mem != stack)
> -               kvfree(mem);
> -
> -       return area->addr;
> +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;

Missing the i = 0 fix from Dan?

> +       vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +       if (pfns != stack)
> +               kvfree(pfns);
> +       return vaddr;
>  }
>
>  /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>         }
>
>         if (!ptr) {
> -               ptr = i915_gem_object_map(obj, type);
> +               if (GEM_WARN_ON(type == I915_MAP_WC &&
> +                               !static_cpu_has(X86_FEATURE_PAT)))
> +                       ptr = NULL;
> +               else if (i915_gem_object_has_struct_page(obj))
> +                       ptr = i915_gem_object_map_page(obj, type);
> +               else
> +                       ptr = i915_gem_object_map_pfn(obj, type);
>                 if (!ptr) {
>                         err = -ENOMEM;
>                         goto err_unpin;
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 14:08     ` Matthew Auld
  0 siblings, 0 replies; 73+ messages in thread
From: Matthew Auld @ 2020-09-25 14:08 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Juergen Gross, Stefano Stabellini, Matthew Wilcox,
	ML dri-devel, linux-mm, Peter Zijlstra, kernel list,
	Intel Graphics Development, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, xen-devel, Boris Ostrovsky, Nitin Gupta

On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig <hch@lst.de> wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig              |   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>  2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>         select CRC32
>         select SND_HDA_I915 if SND_HDA_CORE
>         select CEC_CORE if CEC_NOTIFIER
> +       select VMAP_PFN
>         help
>           Choose this option if you have a system that has "Intel Graphics
>           Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>         return err;
>  }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> -                             dma_addr_t offset,
> -                             pgprot_t prot)
> -{
> -       return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>  /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -                                enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
>  {
> -       unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -       struct sg_table *sgt = obj->mm.pages;
> -       pte_t *stack[32], **mem;
> -       struct vm_struct *area;
> +       unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +       struct page *stack[32], **pages = stack, *page;
> +       struct sgt_iter iter;
>         pgprot_t pgprot;
> +       void *vaddr;
>
> -       if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -               return NULL;
> -
> -       if (GEM_WARN_ON(type == I915_MAP_WC &&
> -                       !static_cpu_has(X86_FEATURE_PAT)))
> -               return NULL;
> -
> -       /* A single page can always be kmapped */
> -       if (n_pte == 1 && type == I915_MAP_WB) {
> -               struct page *page = sg_page(sgt->sgl);
> -
> +       switch (type) {
> +       default:
> +               MISSING_CASE(type);
> +               fallthrough;    /* to use PAGE_KERNEL anyway */
> +       case I915_MAP_WB:
>                 /*
>                  * On 32b, highmem using a finite set of indirect PTE (i.e.
>                  * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                  * So if the page is beyond the 32b boundary, make an explicit
>                  * vmap.
>                  */
> -               if (!PageHighMem(page))
> -                       return page_address(page);
> -       }
> -
> -       mem = stack;
> -       if (n_pte > ARRAY_SIZE(stack)) {
> -               /* Too big for stack -- allocate temporary array instead */
> -               mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -               if (!mem)
> -                       return NULL;
> -       }
> -
> -       area = alloc_vm_area(obj->base.size, mem);
> -       if (!area) {
> -               if (mem != stack)
> -                       kvfree(mem);
> -               return NULL;
> -       }
> -
> -       switch (type) {
> -       default:
> -               MISSING_CASE(type);
> -               fallthrough;    /* to use PAGE_KERNEL anyway */
> -       case I915_MAP_WB:
> +               if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +                       return page_address(sg_page(obj->mm.pages->sgl));
>                 pgprot = PAGE_KERNEL;
>                 break;
>         case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                 break;
>         }
>
> -       if (i915_gem_object_has_struct_page(obj)) {
> -               struct sgt_iter iter;
> -               struct page *page;
> -               pte_t **ptes = mem;
> +       if (n_pages > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +               if (!pages)
> +                       return NULL;
> +       }
>
> -               for_each_sgt_page(page, iter, sgt)
> -                       **ptes++ = mk_pte(page, pgprot);
> -       } else {
> -               resource_size_t iomap;
> -               struct sgt_iter iter;
> -               pte_t **ptes = mem;
> -               dma_addr_t addr;
> +       i = 0;
> +       for_each_sgt_page(page, iter, obj->mm.pages)
> +               pages[i++] = page;
> +       vaddr = vmap(pages, n_pages, 0, pgprot);
> +       if (pages != stack)
> +               kvfree(pages);
> +       return vaddr;
> +}
>
> -               iomap = obj->mm.region->iomap.base;
> -               iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
> +{
> +       resource_size_t iomap = obj->mm.region->iomap.base -
> +               obj->mm.region->region.start;
> +       unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +       unsigned long stack[32], *pfns = stack, i;
> +       struct sgt_iter iter;
> +       dma_addr_t addr;
> +       void *vaddr;
> +
> +       if (type != I915_MAP_WC)
> +               return NULL;
>
> -               for_each_sgt_daddr(addr, iter, sgt)
> -                       **ptes++ = iomap_pte(iomap, addr, pgprot);
> +       if (n_pfn > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +               if (!pfns)
> +                       return NULL;
>         }
>
> -       if (mem != stack)
> -               kvfree(mem);
> -
> -       return area->addr;
> +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;

Missing the i = 0 fix from Dan?

> +       vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +       if (pfns != stack)
> +               kvfree(pfns);
> +       return vaddr;
>  }
>
>  /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>         }
>
>         if (!ptr) {
> -               ptr = i915_gem_object_map(obj, type);
> +               if (GEM_WARN_ON(type == I915_MAP_WC &&
> +                               !static_cpu_has(X86_FEATURE_PAT)))
> +                       ptr = NULL;
> +               else if (i915_gem_object_has_struct_page(obj))
> +                       ptr = i915_gem_object_map_page(obj, type);
> +               else
> +                       ptr = i915_gem_object_map_pfn(obj, type);
>                 if (!ptr) {
>                         err = -ENOMEM;
>                         goto err_unpin;
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 14:08     ` Matthew Auld
  0 siblings, 0 replies; 73+ messages in thread
From: Matthew Auld @ 2020-09-25 14:08 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Juergen Gross, Stefano Stabellini, Minchan Kim, Peter Zijlstra,
	Intel Graphics Development, x86, kernel list, ML dri-devel,
	Chris Wilson, linux-mm, Matthew Wilcox, xen-devel, Andrew Morton,
	Boris Ostrovsky, Nitin Gupta, Matthew Auld

On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig <hch@lst.de> wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig              |   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>  2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>         select CRC32
>         select SND_HDA_I915 if SND_HDA_CORE
>         select CEC_CORE if CEC_NOTIFIER
> +       select VMAP_PFN
>         help
>           Choose this option if you have a system that has "Intel Graphics
>           Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>         return err;
>  }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> -                             dma_addr_t offset,
> -                             pgprot_t prot)
> -{
> -       return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>  /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -                                enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
>  {
> -       unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -       struct sg_table *sgt = obj->mm.pages;
> -       pte_t *stack[32], **mem;
> -       struct vm_struct *area;
> +       unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +       struct page *stack[32], **pages = stack, *page;
> +       struct sgt_iter iter;
>         pgprot_t pgprot;
> +       void *vaddr;
>
> -       if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -               return NULL;
> -
> -       if (GEM_WARN_ON(type == I915_MAP_WC &&
> -                       !static_cpu_has(X86_FEATURE_PAT)))
> -               return NULL;
> -
> -       /* A single page can always be kmapped */
> -       if (n_pte == 1 && type == I915_MAP_WB) {
> -               struct page *page = sg_page(sgt->sgl);
> -
> +       switch (type) {
> +       default:
> +               MISSING_CASE(type);
> +               fallthrough;    /* to use PAGE_KERNEL anyway */
> +       case I915_MAP_WB:
>                 /*
>                  * On 32b, highmem using a finite set of indirect PTE (i.e.
>                  * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                  * So if the page is beyond the 32b boundary, make an explicit
>                  * vmap.
>                  */
> -               if (!PageHighMem(page))
> -                       return page_address(page);
> -       }
> -
> -       mem = stack;
> -       if (n_pte > ARRAY_SIZE(stack)) {
> -               /* Too big for stack -- allocate temporary array instead */
> -               mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -               if (!mem)
> -                       return NULL;
> -       }
> -
> -       area = alloc_vm_area(obj->base.size, mem);
> -       if (!area) {
> -               if (mem != stack)
> -                       kvfree(mem);
> -               return NULL;
> -       }
> -
> -       switch (type) {
> -       default:
> -               MISSING_CASE(type);
> -               fallthrough;    /* to use PAGE_KERNEL anyway */
> -       case I915_MAP_WB:
> +               if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +                       return page_address(sg_page(obj->mm.pages->sgl));
>                 pgprot = PAGE_KERNEL;
>                 break;
>         case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                 break;
>         }
>
> -       if (i915_gem_object_has_struct_page(obj)) {
> -               struct sgt_iter iter;
> -               struct page *page;
> -               pte_t **ptes = mem;
> +       if (n_pages > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +               if (!pages)
> +                       return NULL;
> +       }
>
> -               for_each_sgt_page(page, iter, sgt)
> -                       **ptes++ = mk_pte(page, pgprot);
> -       } else {
> -               resource_size_t iomap;
> -               struct sgt_iter iter;
> -               pte_t **ptes = mem;
> -               dma_addr_t addr;
> +       i = 0;
> +       for_each_sgt_page(page, iter, obj->mm.pages)
> +               pages[i++] = page;
> +       vaddr = vmap(pages, n_pages, 0, pgprot);
> +       if (pages != stack)
> +               kvfree(pages);
> +       return vaddr;
> +}
>
> -               iomap = obj->mm.region->iomap.base;
> -               iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
> +{
> +       resource_size_t iomap = obj->mm.region->iomap.base -
> +               obj->mm.region->region.start;
> +       unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +       unsigned long stack[32], *pfns = stack, i;
> +       struct sgt_iter iter;
> +       dma_addr_t addr;
> +       void *vaddr;
> +
> +       if (type != I915_MAP_WC)
> +               return NULL;
>
> -               for_each_sgt_daddr(addr, iter, sgt)
> -                       **ptes++ = iomap_pte(iomap, addr, pgprot);
> +       if (n_pfn > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +               if (!pfns)
> +                       return NULL;
>         }
>
> -       if (mem != stack)
> -               kvfree(mem);
> -
> -       return area->addr;
> +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;

Missing the i = 0 fix from Dan?

> +       vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +       if (pfns != stack)
> +               kvfree(pfns);
> +       return vaddr;
>  }
>
>  /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>         }
>
>         if (!ptr) {
> -               ptr = i915_gem_object_map(obj, type);
> +               if (GEM_WARN_ON(type == I915_MAP_WC &&
> +                               !static_cpu_has(X86_FEATURE_PAT)))
> +                       ptr = NULL;
> +               else if (i915_gem_object_has_struct_page(obj))
> +                       ptr = i915_gem_object_map_page(obj, type);
> +               else
> +                       ptr = i915_gem_object_map_pfn(obj, type);
>                 if (!ptr) {
>                         err = -ENOMEM;
>                         goto err_unpin;
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 14:08     ` Matthew Auld
  0 siblings, 0 replies; 73+ messages in thread
From: Matthew Auld @ 2020-09-25 14:08 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Juergen Gross, Stefano Stabellini, Minchan Kim, Peter Zijlstra,
	Intel Graphics Development, x86, kernel list, ML dri-devel,
	Chris Wilson, linux-mm, Matthew Wilcox, xen-devel, Andrew Morton,
	Boris Ostrovsky, Nitin Gupta, Matthew Auld

On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig <hch@lst.de> wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig              |   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>  2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>         select CRC32
>         select SND_HDA_I915 if SND_HDA_CORE
>         select CEC_CORE if CEC_NOTIFIER
> +       select VMAP_PFN
>         help
>           Choose this option if you have a system that has "Intel Graphics
>           Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>         return err;
>  }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> -                             dma_addr_t offset,
> -                             pgprot_t prot)
> -{
> -       return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>  /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -                                enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
>  {
> -       unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -       struct sg_table *sgt = obj->mm.pages;
> -       pte_t *stack[32], **mem;
> -       struct vm_struct *area;
> +       unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +       struct page *stack[32], **pages = stack, *page;
> +       struct sgt_iter iter;
>         pgprot_t pgprot;
> +       void *vaddr;
>
> -       if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -               return NULL;
> -
> -       if (GEM_WARN_ON(type == I915_MAP_WC &&
> -                       !static_cpu_has(X86_FEATURE_PAT)))
> -               return NULL;
> -
> -       /* A single page can always be kmapped */
> -       if (n_pte == 1 && type == I915_MAP_WB) {
> -               struct page *page = sg_page(sgt->sgl);
> -
> +       switch (type) {
> +       default:
> +               MISSING_CASE(type);
> +               fallthrough;    /* to use PAGE_KERNEL anyway */
> +       case I915_MAP_WB:
>                 /*
>                  * On 32b, highmem using a finite set of indirect PTE (i.e.
>                  * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                  * So if the page is beyond the 32b boundary, make an explicit
>                  * vmap.
>                  */
> -               if (!PageHighMem(page))
> -                       return page_address(page);
> -       }
> -
> -       mem = stack;
> -       if (n_pte > ARRAY_SIZE(stack)) {
> -               /* Too big for stack -- allocate temporary array instead */
> -               mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -               if (!mem)
> -                       return NULL;
> -       }
> -
> -       area = alloc_vm_area(obj->base.size, mem);
> -       if (!area) {
> -               if (mem != stack)
> -                       kvfree(mem);
> -               return NULL;
> -       }
> -
> -       switch (type) {
> -       default:
> -               MISSING_CASE(type);
> -               fallthrough;    /* to use PAGE_KERNEL anyway */
> -       case I915_MAP_WB:
> +               if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +                       return page_address(sg_page(obj->mm.pages->sgl));
>                 pgprot = PAGE_KERNEL;
>                 break;
>         case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                 break;
>         }
>
> -       if (i915_gem_object_has_struct_page(obj)) {
> -               struct sgt_iter iter;
> -               struct page *page;
> -               pte_t **ptes = mem;
> +       if (n_pages > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +               if (!pages)
> +                       return NULL;
> +       }
>
> -               for_each_sgt_page(page, iter, sgt)
> -                       **ptes++ = mk_pte(page, pgprot);
> -       } else {
> -               resource_size_t iomap;
> -               struct sgt_iter iter;
> -               pte_t **ptes = mem;
> -               dma_addr_t addr;
> +       i = 0;
> +       for_each_sgt_page(page, iter, obj->mm.pages)
> +               pages[i++] = page;
> +       vaddr = vmap(pages, n_pages, 0, pgprot);
> +       if (pages != stack)
> +               kvfree(pages);
> +       return vaddr;
> +}
>
> -               iomap = obj->mm.region->iomap.base;
> -               iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
> +{
> +       resource_size_t iomap = obj->mm.region->iomap.base -
> +               obj->mm.region->region.start;
> +       unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +       unsigned long stack[32], *pfns = stack, i;
> +       struct sgt_iter iter;
> +       dma_addr_t addr;
> +       void *vaddr;
> +
> +       if (type != I915_MAP_WC)
> +               return NULL;
>
> -               for_each_sgt_daddr(addr, iter, sgt)
> -                       **ptes++ = iomap_pte(iomap, addr, pgprot);
> +       if (n_pfn > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +               if (!pfns)
> +                       return NULL;
>         }
>
> -       if (mem != stack)
> -               kvfree(mem);
> -
> -       return area->addr;
> +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;

Missing the i = 0 fix from Dan?

> +       vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +       if (pfns != stack)
> +               kvfree(pfns);
> +       return vaddr;
>  }
>
>  /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>         }
>
>         if (!ptr) {
> -               ptr = i915_gem_object_map(obj, type);
> +               if (GEM_WARN_ON(type == I915_MAP_WC &&
> +                               !static_cpu_has(X86_FEATURE_PAT)))
> +                       ptr = NULL;
> +               else if (i915_gem_object_has_struct_page(obj))
> +                       ptr = i915_gem_object_map_page(obj, type);
> +               else
> +                       ptr = i915_gem_object_map_pfn(obj, type);
>                 if (!ptr) {
>                         err = -ENOMEM;
>                         goto err_unpin;
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 14:08     ` Matthew Auld
  0 siblings, 0 replies; 73+ messages in thread
From: Matthew Auld @ 2020-09-25 14:08 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Juergen Gross, Stefano Stabellini, Matthew Wilcox,
	ML dri-devel, linux-mm, Peter Zijlstra, kernel list,
	Intel Graphics Development, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, xen-devel, Boris Ostrovsky, Nitin Gupta

On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig <hch@lst.de> wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver.  Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig              |   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++++++++++------------
>  2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
>         select CRC32
>         select SND_HDA_I915 if SND_HDA_CORE
>         select CEC_CORE if CEC_NOTIFIER
> +       select VMAP_PFN
>         help
>           Choose this option if you have a system that has "Intel Graphics
>           Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
>         return err;
>  }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> -                             dma_addr_t offset,
> -                             pgprot_t prot)
> -{
> -       return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
>  /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -                                enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
>  {
> -       unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> -       struct sg_table *sgt = obj->mm.pages;
> -       pte_t *stack[32], **mem;
> -       struct vm_struct *area;
> +       unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> +       struct page *stack[32], **pages = stack, *page;
> +       struct sgt_iter iter;
>         pgprot_t pgprot;
> +       void *vaddr;
>
> -       if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> -               return NULL;
> -
> -       if (GEM_WARN_ON(type == I915_MAP_WC &&
> -                       !static_cpu_has(X86_FEATURE_PAT)))
> -               return NULL;
> -
> -       /* A single page can always be kmapped */
> -       if (n_pte == 1 && type == I915_MAP_WB) {
> -               struct page *page = sg_page(sgt->sgl);
> -
> +       switch (type) {
> +       default:
> +               MISSING_CASE(type);
> +               fallthrough;    /* to use PAGE_KERNEL anyway */
> +       case I915_MAP_WB:
>                 /*
>                  * On 32b, highmem using a finite set of indirect PTE (i.e.
>                  * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                  * So if the page is beyond the 32b boundary, make an explicit
>                  * vmap.
>                  */
> -               if (!PageHighMem(page))
> -                       return page_address(page);
> -       }
> -
> -       mem = stack;
> -       if (n_pte > ARRAY_SIZE(stack)) {
> -               /* Too big for stack -- allocate temporary array instead */
> -               mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> -               if (!mem)
> -                       return NULL;
> -       }
> -
> -       area = alloc_vm_area(obj->base.size, mem);
> -       if (!area) {
> -               if (mem != stack)
> -                       kvfree(mem);
> -               return NULL;
> -       }
> -
> -       switch (type) {
> -       default:
> -               MISSING_CASE(type);
> -               fallthrough;    /* to use PAGE_KERNEL anyway */
> -       case I915_MAP_WB:
> +               if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> +                       return page_address(sg_page(obj->mm.pages->sgl));
>                 pgprot = PAGE_KERNEL;
>                 break;
>         case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
>                 break;
>         }
>
> -       if (i915_gem_object_has_struct_page(obj)) {
> -               struct sgt_iter iter;
> -               struct page *page;
> -               pte_t **ptes = mem;
> +       if (n_pages > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> +               if (!pages)
> +                       return NULL;
> +       }
>
> -               for_each_sgt_page(page, iter, sgt)
> -                       **ptes++ = mk_pte(page, pgprot);
> -       } else {
> -               resource_size_t iomap;
> -               struct sgt_iter iter;
> -               pte_t **ptes = mem;
> -               dma_addr_t addr;
> +       i = 0;
> +       for_each_sgt_page(page, iter, obj->mm.pages)
> +               pages[i++] = page;
> +       vaddr = vmap(pages, n_pages, 0, pgprot);
> +       if (pages != stack)
> +               kvfree(pages);
> +       return vaddr;
> +}
>
> -               iomap = obj->mm.region->iomap.base;
> -               iomap -= obj->mm.region->region.start;
> +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
> +               enum i915_map_type type)
> +{
> +       resource_size_t iomap = obj->mm.region->iomap.base -
> +               obj->mm.region->region.start;
> +       unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
> +       unsigned long stack[32], *pfns = stack, i;
> +       struct sgt_iter iter;
> +       dma_addr_t addr;
> +       void *vaddr;
> +
> +       if (type != I915_MAP_WC)
> +               return NULL;
>
> -               for_each_sgt_daddr(addr, iter, sgt)
> -                       **ptes++ = iomap_pte(iomap, addr, pgprot);
> +       if (n_pfn > ARRAY_SIZE(stack)) {
> +               /* Too big for stack -- allocate temporary array instead */
> +               pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
> +               if (!pfns)
> +                       return NULL;
>         }
>
> -       if (mem != stack)
> -               kvfree(mem);
> -
> -       return area->addr;
> +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;

Missing the i = 0 fix from Dan?

> +       vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
> +       if (pfns != stack)
> +               kvfree(pfns);
> +       return vaddr;
>  }
>
>  /* get, pin, and map the pages of the object into kernel space */
> @@ -383,7 +367,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
>         }
>
>         if (!ptr) {
> -               ptr = i915_gem_object_map(obj, type);
> +               if (GEM_WARN_ON(type == I915_MAP_WC &&
> +                               !static_cpu_has(X86_FEATURE_PAT)))
> +                       ptr = NULL;
> +               else if (i915_gem_object_has_struct_page(obj))
> +                       ptr = i915_gem_object_map_page(obj, type);
> +               else
> +                       ptr = i915_gem_object_map_pfn(obj, type);
>                 if (!ptr) {
>                         err = -ENOMEM;
>                         goto err_unpin;
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
  2020-09-25 14:08     ` Matthew Auld
@ 2020-09-25 16:02       ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-25 16:02 UTC (permalink / raw)
  To: Matthew Auld
  Cc: Christoph Hellwig, Andrew Morton, Juergen Gross,
	Stefano Stabellini, Matthew Wilcox, ML dri-devel, linux-mm,
	Peter Zijlstra, kernel list, Intel Graphics Development, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

On Fri, Sep 25, 2020 at 03:08:59PM +0100, Matthew Auld wrote:
> > +       i = 0;
> > +       for_each_sgt_page(page, iter, obj->mm.pages)
> > +               pages[i++] = page;
> > +       vaddr = vmap(pages, n_pages, 0, pgprot);
> > +       if (pages != stack)
> > +               kvfree(pages);
> > +       return vaddr;
> > +}

> > -       return area->addr;
> > +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> > +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
> 
> Missing the i = 0 fix from Dan?

Yeah, looks like I only managed to apply the one in the page based
version above.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 16:02       ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-25 16:02 UTC (permalink / raw)
  To: Matthew Auld
  Cc: Juergen Gross, Stefano Stabellini, Boris Ostrovsky, Minchan Kim,
	Peter Zijlstra, Intel Graphics Development, x86, kernel list,
	ML dri-devel, Chris Wilson, linux-mm, Matthew Wilcox, xen-devel,
	Andrew Morton, Christoph Hellwig, Nitin Gupta, Matthew Auld

On Fri, Sep 25, 2020 at 03:08:59PM +0100, Matthew Auld wrote:
> > +       i = 0;
> > +       for_each_sgt_page(page, iter, obj->mm.pages)
> > +               pages[i++] = page;
> > +       vaddr = vmap(pages, n_pages, 0, pgprot);
> > +       if (pages != stack)
> > +               kvfree(pages);
> > +       return vaddr;
> > +}

> > -       return area->addr;
> > +       for_each_sgt_daddr(addr, iter, obj->mm.pages)
> > +               pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
> 
> Missing the i = 0 fix from Dan?

Yeah, looks like I only managed to apply the one in the page based
version above.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [PATCH 08/11, fixed] drm/i915: use vmap in i915_gem_object_map
  2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
@ 2020-09-25 16:09     ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-25 16:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

i915_gem_object_map implements fairly low-level vmap functionality in
a driver.  Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.

The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig              |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 127 ++++++++++------------
 2 files changed, 60 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
 	select CRC32
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
+	select VMAP_PFN
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..f60ca6dc911f29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 	return err;
 }
 
-static inline pte_t iomap_pte(resource_size_t base,
-			      dma_addr_t offset,
-			      pgprot_t prot)
-{
-	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-				 enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
 {
-	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
-	struct sg_table *sgt = obj->mm.pages;
-	pte_t *stack[32], **mem;
-	struct vm_struct *area;
+	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+	struct page *stack[32], **pages = stack, *page;
+	struct sgt_iter iter;
 	pgprot_t pgprot;
+	void *vaddr;
 
-	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
-		return NULL;
-
-	if (GEM_WARN_ON(type == I915_MAP_WC &&
-			!static_cpu_has(X86_FEATURE_PAT)))
-		return NULL;
-
-	/* A single page can always be kmapped */
-	if (n_pte == 1 && type == I915_MAP_WB) {
-		struct page *page = sg_page(sgt->sgl);
-
+	switch (type) {
+	default:
+		MISSING_CASE(type);
+		fallthrough;	/* to use PAGE_KERNEL anyway */
+	case I915_MAP_WB:
 		/*
 		 * On 32b, highmem using a finite set of indirect PTE (i.e.
 		 * vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * So if the page is beyond the 32b boundary, make an explicit
 		 * vmap.
 		 */
-		if (!PageHighMem(page))
-			return page_address(page);
-	}
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		/* Too big for stack -- allocate temporary array instead */
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
-
-	area = alloc_vm_area(obj->base.size, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
-		return NULL;
-	}
-
-	switch (type) {
-	default:
-		MISSING_CASE(type);
-		fallthrough;	/* to use PAGE_KERNEL anyway */
-	case I915_MAP_WB:
+		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+			return page_address(sg_page(obj->mm.pages->sgl));
 		pgprot = PAGE_KERNEL;
 		break;
 	case I915_MAP_WC:
@@ -308,30 +273,50 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		break;
 	}
 
-	if (i915_gem_object_has_struct_page(obj)) {
-		struct sgt_iter iter;
-		struct page *page;
-		pte_t **ptes = mem;
+	if (n_pages > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+		if (!pages)
+			return NULL;
+	}
 
-		for_each_sgt_page(page, iter, sgt)
-			**ptes++ = mk_pte(page, pgprot);
-	} else {
-		resource_size_t iomap;
-		struct sgt_iter iter;
-		pte_t **ptes = mem;
-		dma_addr_t addr;
+	i = 0;
+	for_each_sgt_page(page, iter, obj->mm.pages)
+		pages[i++] = page;
+	vaddr = vmap(pages, n_pages, 0, pgprot);
+	if (pages != stack)
+		kvfree(pages);
+	return vaddr;
+}
 
-		iomap = obj->mm.region->iomap.base;
-		iomap -= obj->mm.region->region.start;
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
+{
+	resource_size_t iomap = obj->mm.region->iomap.base -
+		obj->mm.region->region.start;
+	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
+	unsigned long stack[32], *pfns = stack, i;
+	struct sgt_iter iter;
+	dma_addr_t addr;
+	void *vaddr;
+
+	if (type != I915_MAP_WC)
+		return NULL;
 
-		for_each_sgt_daddr(addr, iter, sgt)
-			**ptes++ = iomap_pte(iomap, addr, pgprot);
+	if (n_pfn > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
+		if (!pfns)
+			return NULL;
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
-	return area->addr;
+	i = 0;
+	for_each_sgt_daddr(addr, iter, obj->mm.pages)
+		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
+	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
+	if (pfns != stack)
+		kvfree(pfns);
+	return vaddr;
 }
 
 /* get, pin, and map the pages of the object into kernel space */
@@ -383,7 +368,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
 	}
 
 	if (!ptr) {
-		ptr = i915_gem_object_map(obj, type);
+		if (GEM_WARN_ON(type == I915_MAP_WC &&
+				!static_cpu_has(X86_FEATURE_PAT)))
+			ptr = NULL;
+		else if (i915_gem_object_has_struct_page(obj))
+			ptr = i915_gem_object_map_page(obj, type);
+		else
+			ptr = i915_gem_object_map_pfn(obj, type);
 		if (!ptr) {
 			err = -ENOMEM;
 			goto err_unpin;
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] [PATCH 08/11, fixed] drm/i915: use vmap in i915_gem_object_map
@ 2020-09-25 16:09     ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-25 16:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

i915_gem_object_map implements fairly low-level vmap functionality in
a driver.  Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.

The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig              |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 127 ++++++++++------------
 2 files changed, 60 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
 	select CRC32
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
+	select VMAP_PFN
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..f60ca6dc911f29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 	return err;
 }
 
-static inline pte_t iomap_pte(resource_size_t base,
-			      dma_addr_t offset,
-			      pgprot_t prot)
-{
-	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-				 enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
 {
-	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
-	struct sg_table *sgt = obj->mm.pages;
-	pte_t *stack[32], **mem;
-	struct vm_struct *area;
+	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+	struct page *stack[32], **pages = stack, *page;
+	struct sgt_iter iter;
 	pgprot_t pgprot;
+	void *vaddr;
 
-	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
-		return NULL;
-
-	if (GEM_WARN_ON(type == I915_MAP_WC &&
-			!static_cpu_has(X86_FEATURE_PAT)))
-		return NULL;
-
-	/* A single page can always be kmapped */
-	if (n_pte == 1 && type == I915_MAP_WB) {
-		struct page *page = sg_page(sgt->sgl);
-
+	switch (type) {
+	default:
+		MISSING_CASE(type);
+		fallthrough;	/* to use PAGE_KERNEL anyway */
+	case I915_MAP_WB:
 		/*
 		 * On 32b, highmem using a finite set of indirect PTE (i.e.
 		 * vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * So if the page is beyond the 32b boundary, make an explicit
 		 * vmap.
 		 */
-		if (!PageHighMem(page))
-			return page_address(page);
-	}
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		/* Too big for stack -- allocate temporary array instead */
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
-
-	area = alloc_vm_area(obj->base.size, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
-		return NULL;
-	}
-
-	switch (type) {
-	default:
-		MISSING_CASE(type);
-		fallthrough;	/* to use PAGE_KERNEL anyway */
-	case I915_MAP_WB:
+		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+			return page_address(sg_page(obj->mm.pages->sgl));
 		pgprot = PAGE_KERNEL;
 		break;
 	case I915_MAP_WC:
@@ -308,30 +273,50 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		break;
 	}
 
-	if (i915_gem_object_has_struct_page(obj)) {
-		struct sgt_iter iter;
-		struct page *page;
-		pte_t **ptes = mem;
+	if (n_pages > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+		if (!pages)
+			return NULL;
+	}
 
-		for_each_sgt_page(page, iter, sgt)
-			**ptes++ = mk_pte(page, pgprot);
-	} else {
-		resource_size_t iomap;
-		struct sgt_iter iter;
-		pte_t **ptes = mem;
-		dma_addr_t addr;
+	i = 0;
+	for_each_sgt_page(page, iter, obj->mm.pages)
+		pages[i++] = page;
+	vaddr = vmap(pages, n_pages, 0, pgprot);
+	if (pages != stack)
+		kvfree(pages);
+	return vaddr;
+}
 
-		iomap = obj->mm.region->iomap.base;
-		iomap -= obj->mm.region->region.start;
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
+{
+	resource_size_t iomap = obj->mm.region->iomap.base -
+		obj->mm.region->region.start;
+	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
+	unsigned long stack[32], *pfns = stack, i;
+	struct sgt_iter iter;
+	dma_addr_t addr;
+	void *vaddr;
+
+	if (type != I915_MAP_WC)
+		return NULL;
 
-		for_each_sgt_daddr(addr, iter, sgt)
-			**ptes++ = iomap_pte(iomap, addr, pgprot);
+	if (n_pfn > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
+		if (!pfns)
+			return NULL;
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
-	return area->addr;
+	i = 0;
+	for_each_sgt_daddr(addr, iter, obj->mm.pages)
+		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
+	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
+	if (pfns != stack)
+		kvfree(pfns);
+	return vaddr;
 }
 
 /* get, pin, and map the pages of the object into kernel space */
@@ -383,7 +368,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
 	}
 
 	if (!ptr) {
-		ptr = i915_gem_object_map(obj, type);
+		if (GEM_WARN_ON(type == I915_MAP_WC &&
+				!static_cpu_has(X86_FEATURE_PAT)))
+			ptr = NULL;
+		else if (i915_gem_object_has_struct_page(obj))
+			ptr = i915_gem_object_map_page(obj, type);
+		else
+			ptr = i915_gem_object_map_pfn(obj, type);
 		if (!ptr) {
 			err = -ENOMEM;
 			goto err_unpin;
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 73+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] mm: update the documentation for vfree (rev2)
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
                   ` (14 preceding siblings ...)
  (?)
@ 2020-09-25 16:50 ` Patchwork
  -1 siblings, 0 replies; 73+ messages in thread
From: Patchwork @ 2020-09-25 16:50 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 5248 bytes --]

== Series Details ==

Series: series starting with [01/11] mm: update the documentation for vfree (rev2)
URL   : https://patchwork.freedesktop.org/series/82063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9057 -> Patchwork_18576
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/index.html

Known issues
------------

  Here are the changes found in Patchwork_18576 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-bsw-kefka:       [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html

  
#### Possible fixes ####

  * igt@debugfs_test@read_all_entries:
    - fi-bsw-nick:        [INCOMPLETE][3] ([i915#1250] / [i915#1436]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-nick/igt@debugfs_test@read_all_entries.html

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-bsw-kefka:       [INCOMPLETE][5] -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-x1275:       [DMESG-FAIL][7] ([i915#62] / [i915#95]) -> [DMESG-FAIL][8] ([i915#62])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
    - fi-kbl-x1275:       [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html

  * igt@kms_force_connector_basic@prune-stale-modes:
    - fi-kbl-x1275:       [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +2 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html

  * igt@vgem_basic@unload:
    - fi-kbl-x1275:       [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#95])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@vgem_basic@unload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@vgem_basic@unload.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (45 -> 39)
------------------------------

  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9057 -> Patchwork_18576

  CI-20190529: 20190529
  CI_DRM_9057: f812e3c53df08387b5b322aef7f911f21e77aa05 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5788: a7520973a210b7268c3039902789f433ee0f5ef7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18576: c11fe008f1751502cedfffb96abe32165940beae @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c11fe008f175 mm: remove alloc_vm_area
e6569a322009 x86/xen: open code alloc_vm_area in arch_gnttab_valloc
ee890e84c9e2 xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
df7c4a828c36 drm/i915: use vmap in i915_gem_object_map
fd8fa2d72d09 drm/i915: stop using kmap in i915_gem_object_map
179e795ffba4 drm/i915: use vmap in shmem_pin_map
1dae0eeec9bf zsmalloc: switch from alloc_vm_area to get_vm_area
4b84416af184 mm: allow a NULL fn callback in apply_to_page_range
b9e9e60819f1 mm: add a vmap_pfn function
cae4673f131a mm: add a VM_MAP_PUT_PAGES flag for vmap
7433a994ce52 mm: update the documentation for vfree

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/index.html

[-- Attachment #1.2: Type: text/html, Size: 6848 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] mm: update the documentation for vfree (rev2)
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
                   ` (15 preceding siblings ...)
  (?)
@ 2020-09-26  0:08 ` Patchwork
  -1 siblings, 0 replies; 73+ messages in thread
From: Patchwork @ 2020-09-26  0:08 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 14152 bytes --]

== Series Details ==

Series: series starting with [01/11] mm: update the documentation for vfree (rev2)
URL   : https://patchwork.freedesktop.org/series/82063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9057_full -> Patchwork_18576_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_18576_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@feature_discovery@psr2:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@feature_discovery@psr2.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb8/igt@feature_discovery@psr2.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
    - shard-skl:          [PASS][3] -> [TIMEOUT][4] ([i915#1958] / [i915#2424])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl3/igt@gem_userptr_blits@sync-unmap-cycles.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl1/igt@gem_userptr_blits@sync-unmap-cycles.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-skl:          [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl5/igt@gen9_exec_parse@allowed-single.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl3/igt@gen9_exec_parse@allowed-single.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-iclb:         [PASS][7] -> [FAIL][8] ([i915#454])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb8/igt@i915_pm_dc@dc6-psr.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb4/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_selftest@mock@contexts:
    - shard-skl:          [PASS][9] -> [INCOMPLETE][10] ([i915#198] / [i915#2278])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl4/igt@i915_selftest@mock@contexts.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl7/igt@i915_selftest@mock@contexts.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-kbl:          [PASS][11] -> [DMESG-WARN][12] ([i915#180])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl1/igt@i915_suspend@fence-restore-tiled2untiled.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl4/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-skl:          [PASS][13] -> [INCOMPLETE][14] ([i915#300])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl3/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible@ab-vga1-hdmi-a1:
    - shard-hsw:          [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw4/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible@ab-vga1-hdmi-a1.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-hsw6/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible@ab-vga1-hdmi-a1.html

  * igt@kms_flip@flip-vs-suspend@a-edp1:
    - shard-skl:          [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +8 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl7/igt@kms_flip@flip-vs-suspend@a-edp1.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl10/igt@kms_flip@flip-vs-suspend@a-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
    - shard-kbl:          [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-kbl:          [PASS][21] -> [FAIL][22] ([i915#1188])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl7/igt@kms_hdr@bpc-switch-suspend.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl7/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb7/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
    - shard-iclb:         [PASS][25] -> [SKIP][26] ([fdo#109441]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html

  * igt@perf@polling-parameterized:
    - shard-kbl:          [PASS][27] -> [FAIL][28] ([i915#1542])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl1/igt@perf@polling-parameterized.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl4/igt@perf@polling-parameterized.html

  
#### Possible fixes ####

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         [SKIP][29] ([i915#2190]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-tglb6/igt@gem_huc_copy@huc-copy.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-tglb8/igt@gem_huc_copy@huc-copy.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
    - shard-glk:          [FAIL][31] ([i915#644]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-glk5/igt@gem_ppgtt@flink-and-close-vma-leak.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-glk5/igt@gem_ppgtt@flink-and-close-vma-leak.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
    - shard-skl:          [TIMEOUT][33] ([i915#1958]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl6/igt@gem_userptr_blits@unsync-unmap-cycles.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl2/igt@gem_userptr_blits@unsync-unmap-cycles.html

  * igt@i915_selftest@mock@contexts:
    - shard-apl:          [INCOMPLETE][35] ([i915#1635] / [i915#2278]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-apl2/igt@i915_selftest@mock@contexts.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-apl2/igt@i915_selftest@mock@contexts.html

  * igt@i915_suspend@forcewake:
    - shard-kbl:          [DMESG-WARN][37] ([i915#180]) -> [PASS][38] +1 similar issue
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl6/igt@i915_suspend@forcewake.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl2/igt@i915_suspend@forcewake.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-180:
    - shard-apl:          [DMESG-WARN][39] ([i915#1635] / [i915#1982]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-apl2/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-apl2/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          [FAIL][41] ([i915#96]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-hsw4/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
    - shard-skl:          [DMESG-WARN][43] ([i915#1982]) -> [PASS][44] +2 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl6/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl2/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html

  * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions:
    - shard-tglb:         [DMESG-WARN][45] ([i915#1982]) -> [PASS][46] +3 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-tglb2/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-tglb2/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html

  * igt@kms_draw_crc@fill-fb:
    - shard-skl:          [FAIL][47] ([i915#52]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl1/igt@kms_draw_crc@fill-fb.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl10/igt@kms_draw_crc@fill-fb.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
    - shard-skl:          [FAIL][49] ([i915#79]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][51] ([fdo#108145] / [i915#265]) -> [PASS][52] +1 similar issue
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
    - shard-iclb:         [DMESG-WARN][53] ([i915#1982]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb3/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb5/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [SKIP][55] ([fdo#109642] / [fdo#111068]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb1/igt@kms_psr2_su@frontbuffer.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb2/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][57] ([fdo#109441]) -> [PASS][58] +3 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc3co-vpb-simulation:
    - shard-iclb:         [SKIP][59] ([i915#588]) -> [SKIP][60] ([i915#658])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb7/igt@i915_pm_dc@dc3co-vpb-simulation.html

  * igt@kms_color@pipe-c-ctm-max:
    - shard-skl:          [DMESG-WARN][61] ([i915#1982]) -> [DMESG-FAIL][62] ([i915#1982])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl10/igt@kms_color@pipe-c-ctm-max.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl6/igt@kms_color@pipe-c-ctm-max.html

  
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2278]: https://gitlab.freedesktop.org/drm/intel/issues/2278
  [i915#2424]: https://gitlab.freedesktop.org/drm/intel/issues/2424
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
  [i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
  [i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96


Participating hosts (10 -> 11)
------------------------------

  Additional (1): pig-icl-1065g7 


Build changes
-------------

  * Linux: CI_DRM_9057 -> Patchwork_18576

  CI-20190529: 20190529
  CI_DRM_9057: f812e3c53df08387b5b322aef7f911f21e77aa05 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5788: a7520973a210b7268c3039902789f433ee0f5ef7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18576: c11fe008f1751502cedfffb96abe32165940beae @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/index.html

[-- Attachment #1.2: Type: text/html, Size: 16580 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-26  2:43   ` Andrew Morton
  -1 siblings, 0 replies; 73+ messages in thread
From: Andrew Morton @ 2020-09-26  2:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:

> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework.  It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area.  It was originally addeds for Xen (which isn't
> modular to start with), and then grew users in zsmalloc and i915
> which seems to mostly qualify as abuses of the interface, especially
> for i915 as a random driver should not set up PTE bits directly.
> 
> Note that the i915 patches apply to the drm-tip branch of the drm-tip
> tree, as that tree has recent conflicting commits in the same area.

Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
reject in there at present.


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
@ 2020-09-26  2:43   ` Andrew Morton
  0 siblings, 0 replies; 73+ messages in thread
From: Andrew Morton @ 2020-09-26  2:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Juergen Gross, Tvrtko Ursulin, Stefano Stabellini,
	Matthew Wilcox, dri-devel, linux-mm, Peter Zijlstra,
	linux-kernel, intel-gfx, x86, Chris Wilson, Minchan Kim,
	Matthew Auld, Rodrigo Vivi, xen-devel, Boris Ostrovsky,
	Nitin Gupta

On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:

> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework.  It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area.  It was originally addeds for Xen (which isn't
> modular to start with), and then grew users in zsmalloc and i915
> which seems to mostly qualify as abuses of the interface, especially
> for i915 as a random driver should not set up PTE bits directly.
> 
> Note that the i915 patches apply to the drm-tip branch of the drm-tip
> tree, as that tree has recent conflicting commits in the same area.

Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
reject in there at present.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-26  2:43   ` Andrew Morton
  0 siblings, 0 replies; 73+ messages in thread
From: Andrew Morton @ 2020-09-26  2:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Nitin Gupta

On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:

> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework.  It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area.  It was originally addeds for Xen (which isn't
> modular to start with), and then grew users in zsmalloc and i915
> which seems to mostly qualify as abuses of the interface, especially
> for i915 as a random driver should not set up PTE bits directly.
> 
> Note that the i915 patches apply to the drm-tip branch of the drm-tip
> tree, as that tree has recent conflicting commits in the same area.

Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
reject in there at present.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-26  2:43   ` Andrew Morton
@ 2020-09-26  6:29     ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-26  6:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Hellwig, Peter Zijlstra, Boris Ostrovsky,
	Juergen Gross, Stefano Stabellini, Jani Nikula, Joonas Lahtinen,
	Tvrtko Ursulin, Chris Wilson, Matthew Auld, Rodrigo Vivi,
	Minchan Kim, Matthew Wilcox, Nitin Gupta, x86, xen-devel,
	linux-kernel, intel-gfx, dri-devel, linux-mm

On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:
> 
> > this series removes alloc_vm_area, which was left over from the big
> > vmalloc interface rework.  It is a rather arkane interface, basicaly
> > the equivalent of get_vm_area + actually faulting in all PTEs in
> > the allocated area.  It was originally addeds for Xen (which isn't
> > modular to start with), and then grew users in zsmalloc and i915
> > which seems to mostly qualify as abuses of the interface, especially
> > for i915 as a random driver should not set up PTE bits directly.
> > 
> > Note that the i915 patches apply to the drm-tip branch of the drm-tip
> > tree, as that tree has recent conflicting commits in the same area.
> 
> Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
> reject in there at present.

I assumed it was, but the reject imply that they aren't.  Tvrtko, do you
know the details?

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-26  6:29     ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-26  6:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, linux-kernel, intel-gfx, x86,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Christoph Hellwig, Nitin Gupta

On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:
> 
> > this series removes alloc_vm_area, which was left over from the big
> > vmalloc interface rework.  It is a rather arkane interface, basicaly
> > the equivalent of get_vm_area + actually faulting in all PTEs in
> > the allocated area.  It was originally addeds for Xen (which isn't
> > modular to start with), and then grew users in zsmalloc and i915
> > which seems to mostly qualify as abuses of the interface, especially
> > for i915 as a random driver should not set up PTE bits directly.
> > 
> > Note that the i915 patches apply to the drm-tip branch of the drm-tip
> > tree, as that tree has recent conflicting commits in the same area.
> 
> Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
> reject in there at present.

I assumed it was, but the reject imply that they aren't.  Tvrtko, do you
know the details?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-26  6:29     ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-28 10:13       ` Joonas Lahtinen
  -1 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-28 10:13 UTC (permalink / raw)
  To: Andrew Morton, Christoph Hellwig, David Airlie, Daniel Vetter,
	Stephen Rothwell
  Cc: Christoph Hellwig, Peter Zijlstra, Boris Ostrovsky,
	Juergen Gross, Stefano Stabellini, Jani Nikula, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm

+ Dave and Daniel
+ Stephen

Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:
> > 
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc interface rework.  It is a rather arkane interface, basicaly
> > > the equivalent of get_vm_area + actually faulting in all PTEs in
> > > the allocated area.  It was originally addeds for Xen (which isn't
> > > modular to start with), and then grew users in zsmalloc and i915
> > > which seems to mostly qualify as abuses of the interface, especially
> > > for i915 as a random driver should not set up PTE bits directly.
> > > 
> > > Note that the i915 patches apply to the drm-tip branch of the drm-tip
> > > tree, as that tree has recent conflicting commits in the same area.
> > 
> > Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
> > reject in there at present.
> 
> I assumed it was, but the reject imply that they aren't.  Tvrtko, do you
> know the details?

I think we have a gap that after splitting the drm-intel-next pull requests into
two the drm-intel/for-linux-next branch is now missing material from
drm-intel/drm-intel-gt-next.

I think a simple course of action might be to start including drm-intel-gt-next
in linux-next, which would mean that we should update DIM tooling to add
extra branch "drm-intel/gt-for-linux-next" or so.

Which specific patches are missing in this case?

Regards, Joonas

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
@ 2020-09-28 10:13       ` Joonas Lahtinen
  0 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-28 10:13 UTC (permalink / raw)
  To: Andrew Morton, Christoph Hellwig, David Airlie, Daniel Vetter,
	Stephen Rothwell
  Cc: Juergen Gross, Tvrtko Ursulin, Stefano Stabellini,
	Matthew Wilcox, dri-devel, linux-mm, Peter Zijlstra, intel-gfx,
	x86, linux-kernel, Chris Wilson, Minchan Kim, Matthew Auld,
	Rodrigo Vivi, xen-devel, Boris Ostrovsky, Christoph Hellwig,
	Nitin Gupta

+ Dave and Daniel
+ Stephen

Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:
> > 
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc interface rework.  It is a rather arkane interface, basicaly
> > > the equivalent of get_vm_area + actually faulting in all PTEs in
> > > the allocated area.  It was originally addeds for Xen (which isn't
> > > modular to start with), and then grew users in zsmalloc and i915
> > > which seems to mostly qualify as abuses of the interface, especially
> > > for i915 as a random driver should not set up PTE bits directly.
> > > 
> > > Note that the i915 patches apply to the drm-tip branch of the drm-tip
> > > tree, as that tree has recent conflicting commits in the same area.
> > 
> > Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
> > reject in there at present.
> 
> I assumed it was, but the reject imply that they aren't.  Tvrtko, do you
> know the details?

I think we have a gap that after splitting the drm-intel-next pull requests into
two the drm-intel/for-linux-next branch is now missing material from
drm-intel/drm-intel-gt-next.

I think a simple course of action might be to start including drm-intel-gt-next
in linux-next, which would mean that we should update DIM tooling to add
extra branch "drm-intel/gt-for-linux-next" or so.

Which specific patches are missing in this case?

Regards, Joonas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-28 10:13       ` Joonas Lahtinen
  0 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-28 10:13 UTC (permalink / raw)
  To: Andrew Morton, Christoph Hellwig, David Airlie, Daniel Vetter,
	Stephen Rothwell
  Cc: Juergen Gross, Stefano Stabellini, Matthew Wilcox, dri-devel,
	linux-mm, Peter Zijlstra, intel-gfx, x86, linux-kernel,
	Chris Wilson, Minchan Kim, Matthew Auld, xen-devel,
	Boris Ostrovsky, Christoph Hellwig, Nitin Gupta

+ Dave and Daniel
+ Stephen

Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig <hch@lst.de> wrote:
> > 
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc interface rework.  It is a rather arkane interface, basicaly
> > > the equivalent of get_vm_area + actually faulting in all PTEs in
> > > the allocated area.  It was originally addeds for Xen (which isn't
> > > modular to start with), and then grew users in zsmalloc and i915
> > > which seems to mostly qualify as abuses of the interface, especially
> > > for i915 as a random driver should not set up PTE bits directly.
> > > 
> > > Note that the i915 patches apply to the drm-tip branch of the drm-tip
> > > tree, as that tree has recent conflicting commits in the same area.
> > 
> > Is the drm-tip material in linux-next yet?  I'm still seeing a non-trivial
> > reject in there at present.
> 
> I assumed it was, but the reject imply that they aren't.  Tvrtko, do you
> know the details?

I think we have a gap that after splitting the drm-intel-next pull requests into
two the drm-intel/for-linux-next branch is now missing material from
drm-intel/drm-intel-gt-next.

I think a simple course of action might be to start including drm-intel-gt-next
in linux-next, which would mean that we should update DIM tooling to add
extra branch "drm-intel/gt-for-linux-next" or so.

Which specific patches are missing in this case?

Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-28 10:13       ` Joonas Lahtinen
@ 2020-09-28 12:37         ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-28 12:37 UTC (permalink / raw)
  To: Joonas Lahtinen
  Cc: Andrew Morton, Christoph Hellwig, David Airlie, Daniel Vetter,
	Stephen Rothwell, Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Tvrtko Ursulin, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm

On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> I think we have a gap that after splitting the drm-intel-next pull requests into
> two the drm-intel/for-linux-next branch is now missing material from
> drm-intel/drm-intel-gt-next.
> 
> I think a simple course of action might be to start including drm-intel-gt-next
> in linux-next, which would mean that we should update DIM tooling to add
> extra branch "drm-intel/gt-for-linux-next" or so.
> 
> Which specific patches are missing in this case?

The two dependencies required by my series not in mainline are:

    drm/i915/gem: Avoid implicit vmap for highmem on x86-32
    drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported

so it has to be one or both of those.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-28 12:37         ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-28 12:37 UTC (permalink / raw)
  To: Joonas Lahtinen
  Cc: David Airlie, dri-devel, Chris Wilson, linux-mm,
	Christoph Hellwig, Stephen Rothwell, Stefano Stabellini, x86,
	Matthew Wilcox, Peter Zijlstra, Matthew Auld, xen-devel,
	Nitin Gupta, intel-gfx, Boris Ostrovsky, Juergen Gross,
	linux-kernel, Minchan Kim, Andrew Morton

On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> I think we have a gap that after splitting the drm-intel-next pull requests into
> two the drm-intel/for-linux-next branch is now missing material from
> drm-intel/drm-intel-gt-next.
> 
> I think a simple course of action might be to start including drm-intel-gt-next
> in linux-next, which would mean that we should update DIM tooling to add
> extra branch "drm-intel/gt-for-linux-next" or so.
> 
> Which specific patches are missing in this case?

The two dependencies required by my series not in mainline are:

    drm/i915/gem: Avoid implicit vmap for highmem on x86-32
    drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported

so it has to be one or both of those.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-28 12:37         ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2020-09-29 12:43           ` Joonas Lahtinen
  -1 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-29 12:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Christoph Hellwig, David Airlie, Daniel Vetter,
	Stephen Rothwell, Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Tvrtko Ursulin, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm

Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests into
> > two the drm-intel/for-linux-next branch is now missing material from
> > drm-intel/drm-intel-gt-next.
> > 
> > I think a simple course of action might be to start including drm-intel-gt-next
> > in linux-next, which would mean that we should update DIM tooling to add
> > extra branch "drm-intel/gt-for-linux-next" or so.
> > 
> > Which specific patches are missing in this case?
> 
> The two dependencies required by my series not in mainline are:
> 
>     drm/i915/gem: Avoid implicit vmap for highmem on x86-32
>     drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported
> 
> so it has to be one or both of those.

Hmm, those are both committed after our last -next pull request, so they
would normally only target next merge window. drm-next closes the merge
window around -rc5 already.

But, in this specific case those are both Fixes: patches with Cc: stable,
so they should be pulled into drm-intel-next-fixes PR.

Rodrigo, can you cherry-pick those patches to -next-fixes that you send
to Dave?

Regards, Joonas

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
@ 2020-09-29 12:43           ` Joonas Lahtinen
  0 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-29 12:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: David Airlie, dri-devel, Chris Wilson, linux-mm,
	Christoph Hellwig, Stephen Rothwell, Stefano Stabellini, x86,
	Matthew Wilcox, Peter Zijlstra, Matthew Auld, xen-devel,
	Nitin Gupta, intel-gfx, Rodrigo Vivi, Boris Ostrovsky,
	Juergen Gross, Tvrtko Ursulin, linux-kernel, Minchan Kim,
	Andrew Morton

Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests into
> > two the drm-intel/for-linux-next branch is now missing material from
> > drm-intel/drm-intel-gt-next.
> > 
> > I think a simple course of action might be to start including drm-intel-gt-next
> > in linux-next, which would mean that we should update DIM tooling to add
> > extra branch "drm-intel/gt-for-linux-next" or so.
> > 
> > Which specific patches are missing in this case?
> 
> The two dependencies required by my series not in mainline are:
> 
>     drm/i915/gem: Avoid implicit vmap for highmem on x86-32
>     drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported
> 
> so it has to be one or both of those.

Hmm, those are both committed after our last -next pull request, so they
would normally only target next merge window. drm-next closes the merge
window around -rc5 already.

But, in this specific case those are both Fixes: patches with Cc: stable,
so they should be pulled into drm-intel-next-fixes PR.

Rodrigo, can you cherry-pick those patches to -next-fixes that you send
to Dave?

Regards, Joonas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-29 12:43           ` Joonas Lahtinen
  0 siblings, 0 replies; 73+ messages in thread
From: Joonas Lahtinen @ 2020-09-29 12:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: David Airlie, dri-devel, Chris Wilson, linux-mm,
	Christoph Hellwig, Stephen Rothwell, Stefano Stabellini, x86,
	Matthew Wilcox, Peter Zijlstra, Matthew Auld, xen-devel,
	Nitin Gupta, intel-gfx, Boris Ostrovsky, Juergen Gross,
	linux-kernel, Minchan Kim, Andrew Morton

Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests into
> > two the drm-intel/for-linux-next branch is now missing material from
> > drm-intel/drm-intel-gt-next.
> > 
> > I think a simple course of action might be to start including drm-intel-gt-next
> > in linux-next, which would mean that we should update DIM tooling to add
> > extra branch "drm-intel/gt-for-linux-next" or so.
> > 
> > Which specific patches are missing in this case?
> 
> The two dependencies required by my series not in mainline are:
> 
>     drm/i915/gem: Avoid implicit vmap for highmem on x86-32
>     drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported
> 
> so it has to be one or both of those.

Hmm, those are both committed after our last -next pull request, so they
would normally only target next merge window. drm-next closes the merge
window around -rc5 already.

But, in this specific case those are both Fixes: patches with Cc: stable,
so they should be pulled into drm-intel-next-fixes PR.

Rodrigo, can you cherry-pick those patches to -next-fixes that you send
to Dave?

Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-29 12:43           ` Joonas Lahtinen
@ 2020-09-30 14:48             ` Christoph Hellwig
  -1 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-30 14:48 UTC (permalink / raw)
  To: Joonas Lahtinen
  Cc: Christoph Hellwig, Andrew Morton, David Airlie, Daniel Vetter,
	Stephen Rothwell, Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Tvrtko Ursulin, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, x86, xen-devel, linux-kernel, intel-gfx, dri-devel,
	linux-mm

On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> Hmm, those are both committed after our last -next pull request, so they
> would normally only target next merge window. drm-next closes the merge
> window around -rc5 already.
> 
> But, in this specific case those are both Fixes: patches with Cc: stable,
> so they should be pulled into drm-intel-next-fixes PR.
> 
> Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> to Dave?

They still haven't made it to linux-next.  I think for now I'll just
rebase without them again and then you can handle the conflicts for
5.11.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-30 14:48             ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-09-30 14:48 UTC (permalink / raw)
  To: Joonas Lahtinen
  Cc: David Airlie, dri-devel, Chris Wilson, linux-mm,
	Christoph Hellwig, Stephen Rothwell, Stefano Stabellini, x86,
	Matthew Wilcox, Peter Zijlstra, Matthew Auld, xen-devel,
	Nitin Gupta, intel-gfx, Boris Ostrovsky, Juergen Gross,
	linux-kernel, Minchan Kim, Andrew Morton

On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> Hmm, those are both committed after our last -next pull request, so they
> would normally only target next merge window. drm-next closes the merge
> window around -rc5 already.
> 
> But, in this specific case those are both Fixes: patches with Cc: stable,
> so they should be pulled into drm-intel-next-fixes PR.
> 
> Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> to Dave?

They still haven't made it to linux-next.  I think for now I'll just
rebase without them again and then you can handle the conflicts for
5.11.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
  2020-09-30 14:48             ` [Intel-gfx] " Christoph Hellwig
  (?)
  (?)
@ 2020-09-30 18:37               ` Daniel Vetter
  -1 siblings, 0 replies; 73+ messages in thread
From: Daniel Vetter @ 2020-09-30 18:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Joonas Lahtinen, Andrew Morton, David Airlie, Stephen Rothwell,
	Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Tvrtko Ursulin, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, X86 ML, moderated list:DRM DRIVERS FOR XEN,
	Linux Kernel Mailing List, intel-gfx, dri-devel, Linux MM

On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around -rc5 already.
> >
> > But, in this specific case those are both Fixes: patches with Cc: stable,
> > so they should be pulled into drm-intel-next-fixes PR.
> >
> > Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> > to Dave?
>
> They still haven't made it to linux-next.  I think for now I'll just
> rebase without them again and then you can handle the conflicts for
> 5.11.

Yeah after -rc6 drm is frozen for features, so anything that's stuck
in subordinate trees rolls over to the next merge cycle. To avoid
upsetting sfr from linux-next we keep those -next branches out of
linux-next until after -rc1 again. iow, rebasing onto linux-next and
smashing this into 5.10 sounds like the right approach (since everyone
else freezes a bunch later afaik).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
@ 2020-09-30 18:37               ` Daniel Vetter
  0 siblings, 0 replies; 73+ messages in thread
From: Daniel Vetter @ 2020-09-30 18:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Joonas Lahtinen, Andrew Morton, David Airlie, Stephen Rothwell,
	Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Tvrtko Ursulin, Chris Wilson,
	Matthew Auld, Rodrigo Vivi, Minchan Kim, Matthew Wilcox,
	Nitin Gupta, X86 ML, moderated list:DRM DRIVERS FOR XEN,
	Linux Kernel Mailing List, intel-gfx, dri-devel, Linux MM

On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around -rc5 already.
> >
> > But, in this specific case those are both Fixes: patches with Cc: stable,
> > so they should be pulled into drm-intel-next-fixes PR.
> >
> > Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> > to Dave?
>
> They still haven't made it to linux-next.  I think for now I'll just
> rebase without them again and then you can handle the conflicts for
> 5.11.

Yeah after -rc6 drm is frozen for features, so anything that's stuck
in subordinate trees rolls over to the next merge cycle. To avoid
upsetting sfr from linux-next we keep those -next branches out of
linux-next until after -rc1 again. iow, rebasing onto linux-next and
smashing this into 5.10 sounds like the right approach (since everyone
else freezes a bunch later afaik).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: remove alloc_vm_area v2
@ 2020-09-30 18:37               ` Daniel Vetter
  0 siblings, 0 replies; 73+ messages in thread
From: Daniel Vetter @ 2020-09-30 18:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: David Airlie, dri-devel, Chris Wilson, Linux MM,
	Stephen Rothwell, Stefano Stabellini, X86 ML, Matthew Wilcox,
	Peter Zijlstra, Matthew Auld, moderated list:DRM DRIVERS FOR XEN,
	Nitin Gupta, intel-gfx, Rodrigo Vivi, Boris Ostrovsky,
	Juergen Gross, Tvrtko Ursulin, Linux Kernel Mailing List,
	Minchan Kim, Andrew Morton

On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around -rc5 already.
> >
> > But, in this specific case those are both Fixes: patches with Cc: stable,
> > so they should be pulled into drm-intel-next-fixes PR.
> >
> > Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> > to Dave?
>
> They still haven't made it to linux-next.  I think for now I'll just
> rebase without them again and then you can handle the conflicts for
> 5.11.

Yeah after -rc6 drm is frozen for features, so anything that's stuck
in subordinate trees rolls over to the next merge cycle. To avoid
upsetting sfr from linux-next we keep those -next branches out of
linux-next until after -rc1 again. iow, rebasing onto linux-next and
smashing this into 5.10 sounds like the right approach (since everyone
else freezes a bunch later afaik).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [Intel-gfx] remove alloc_vm_area v2
@ 2020-09-30 18:37               ` Daniel Vetter
  0 siblings, 0 replies; 73+ messages in thread
From: Daniel Vetter @ 2020-09-30 18:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: David Airlie, dri-devel, Chris Wilson, Linux MM,
	Stephen Rothwell, Stefano Stabellini, X86 ML, Matthew Wilcox,
	Peter Zijlstra, Matthew Auld, moderated list:DRM DRIVERS FOR XEN,
	Nitin Gupta, intel-gfx, Boris Ostrovsky, Juergen Gross,
	Linux Kernel Mailing List, Minchan Kim, Andrew Morton

On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around -rc5 already.
> >
> > But, in this specific case those are both Fixes: patches with Cc: stable,
> > so they should be pulled into drm-intel-next-fixes PR.
> >
> > Rodrigo, can you cherry-pick those patches to -next-fixes that you send
> > to Dave?
>
> They still haven't made it to linux-next.  I think for now I'll just
> rebase without them again and then you can handle the conflicts for
> 5.11.

Yeah after -rc6 drm is frozen for features, so anything that's stuck
in subordinate trees rolls over to the next merge cycle. To avoid
upsetting sfr from linux-next we keep those -next branches out of
linux-next until after -rc1 again. iow, rebasing onto linux-next and
smashing this into 5.10 sounds like the right approach (since everyone
else freezes a bunch later afaik).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 73+ messages in thread

* [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
  2020-10-02 12:21 remove alloc_vm_area v4 Christoph Hellwig
@ 2020-10-02 12:22 ` Christoph Hellwig
  0 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-10-02 12:22 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Zijlstra, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin,
	Chris Wilson, Matthew Auld, Rodrigo Vivi, Minchan Kim,
	Matthew Wilcox, Nitin Gupta, x86, xen-devel, linux-kernel,
	intel-gfx, dri-devel, linux-mm, Tvrtko Ursulin

i915_gem_object_map implements fairly low-level vmap functionality in
a driver.  Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.

The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/Kconfig              |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 127 ++++++++++------------
 2 files changed, 60 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
 	select CRC32
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
+	select VMAP_PFN
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..f60ca6dc911f29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 	return err;
 }
 
-static inline pte_t iomap_pte(resource_size_t base,
-			      dma_addr_t offset,
-			      pgprot_t prot)
-{
-	return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-				 enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
 {
-	unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
-	struct sg_table *sgt = obj->mm.pages;
-	pte_t *stack[32], **mem;
-	struct vm_struct *area;
+	unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+	struct page *stack[32], **pages = stack, *page;
+	struct sgt_iter iter;
 	pgprot_t pgprot;
+	void *vaddr;
 
-	if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
-		return NULL;
-
-	if (GEM_WARN_ON(type == I915_MAP_WC &&
-			!static_cpu_has(X86_FEATURE_PAT)))
-		return NULL;
-
-	/* A single page can always be kmapped */
-	if (n_pte == 1 && type == I915_MAP_WB) {
-		struct page *page = sg_page(sgt->sgl);
-
+	switch (type) {
+	default:
+		MISSING_CASE(type);
+		fallthrough;	/* to use PAGE_KERNEL anyway */
+	case I915_MAP_WB:
 		/*
 		 * On 32b, highmem using a finite set of indirect PTE (i.e.
 		 * vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		 * So if the page is beyond the 32b boundary, make an explicit
 		 * vmap.
 		 */
-		if (!PageHighMem(page))
-			return page_address(page);
-	}
-
-	mem = stack;
-	if (n_pte > ARRAY_SIZE(stack)) {
-		/* Too big for stack -- allocate temporary array instead */
-		mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
-		if (!mem)
-			return NULL;
-	}
-
-	area = alloc_vm_area(obj->base.size, mem);
-	if (!area) {
-		if (mem != stack)
-			kvfree(mem);
-		return NULL;
-	}
-
-	switch (type) {
-	default:
-		MISSING_CASE(type);
-		fallthrough;	/* to use PAGE_KERNEL anyway */
-	case I915_MAP_WB:
+		if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+			return page_address(sg_page(obj->mm.pages->sgl));
 		pgprot = PAGE_KERNEL;
 		break;
 	case I915_MAP_WC:
@@ -308,30 +273,50 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
 		break;
 	}
 
-	if (i915_gem_object_has_struct_page(obj)) {
-		struct sgt_iter iter;
-		struct page *page;
-		pte_t **ptes = mem;
+	if (n_pages > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+		if (!pages)
+			return NULL;
+	}
 
-		for_each_sgt_page(page, iter, sgt)
-			**ptes++ = mk_pte(page, pgprot);
-	} else {
-		resource_size_t iomap;
-		struct sgt_iter iter;
-		pte_t **ptes = mem;
-		dma_addr_t addr;
+	i = 0;
+	for_each_sgt_page(page, iter, obj->mm.pages)
+		pages[i++] = page;
+	vaddr = vmap(pages, n_pages, 0, pgprot);
+	if (pages != stack)
+		kvfree(pages);
+	return vaddr;
+}
 
-		iomap = obj->mm.region->iomap.base;
-		iomap -= obj->mm.region->region.start;
+static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj,
+		enum i915_map_type type)
+{
+	resource_size_t iomap = obj->mm.region->iomap.base -
+		obj->mm.region->region.start;
+	unsigned long n_pfn = obj->base.size >> PAGE_SHIFT;
+	unsigned long stack[32], *pfns = stack, i;
+	struct sgt_iter iter;
+	dma_addr_t addr;
+	void *vaddr;
+
+	if (type != I915_MAP_WC)
+		return NULL;
 
-		for_each_sgt_daddr(addr, iter, sgt)
-			**ptes++ = iomap_pte(iomap, addr, pgprot);
+	if (n_pfn > ARRAY_SIZE(stack)) {
+		/* Too big for stack -- allocate temporary array instead */
+		pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL);
+		if (!pfns)
+			return NULL;
 	}
 
-	if (mem != stack)
-		kvfree(mem);
-
-	return area->addr;
+	i = 0;
+	for_each_sgt_daddr(addr, iter, obj->mm.pages)
+		pfns[i++] = (iomap + addr) >> PAGE_SHIFT;
+	vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO));
+	if (pfns != stack)
+		kvfree(pfns);
+	return vaddr;
 }
 
 /* get, pin, and map the pages of the object into kernel space */
@@ -383,7 +368,13 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
 	}
 
 	if (!ptr) {
-		ptr = i915_gem_object_map(obj, type);
+		if (GEM_WARN_ON(type == I915_MAP_WC &&
+				!static_cpu_has(X86_FEATURE_PAT)))
+			ptr = NULL;
+		else if (i915_gem_object_has_struct_page(obj))
+			ptr = i915_gem_object_map_page(obj, type);
+		else
+			ptr = i915_gem_object_map_pfn(obj, type);
 		if (!ptr) {
 			err = -ENOMEM;
 			goto err_unpin;
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 73+ messages in thread

end of thread, other threads:[~2020-10-02 12:22 UTC | newest]

Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-24 13:58 remove alloc_vm_area v2 Christoph Hellwig
2020-09-24 13:58 ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 01/11] mm: update the documentation for vfree Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 02/11] mm: add a VM_MAP_PUT_PAGES flag for vmap Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 03/11] mm: add a vmap_pfn function Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 04/11] mm: allow a NULL fn callback in apply_to_page_range Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 05/11] zsmalloc: switch from alloc_vm_area to get_vm_area Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 06/11] drm/i915: use vmap in shmem_pin_map Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-25 13:05   ` Tvrtko Ursulin
2020-09-25 13:05     ` [Intel-gfx] " Tvrtko Ursulin
2020-09-25 13:05     ` Tvrtko Ursulin
2020-09-24 13:58 ` [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-25 13:01   ` Tvrtko Ursulin
2020-09-25 13:01     ` [Intel-gfx] " Tvrtko Ursulin
2020-09-25 13:01     ` Tvrtko Ursulin
2020-09-24 13:58 ` [PATCH 08/11] drm/i915: use vmap " Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-25 13:11   ` Tvrtko Ursulin
2020-09-25 13:11     ` [Intel-gfx] " Tvrtko Ursulin
2020-09-25 13:11     ` Tvrtko Ursulin
2020-09-25 14:08   ` [Intel-gfx] " Matthew Auld
2020-09-25 14:08     ` Matthew Auld
2020-09-25 14:08     ` Matthew Auld
2020-09-25 14:08     ` Matthew Auld
2020-09-25 14:08     ` Matthew Auld
2020-09-25 16:02     ` Christoph Hellwig
2020-09-25 16:02       ` Christoph Hellwig
2020-09-25 16:09   ` [PATCH 08/11, fixed] " Christoph Hellwig
2020-09-25 16:09     ` [Intel-gfx] " Christoph Hellwig
2020-09-24 13:58 ` [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 23:42   ` boris.ostrovsky
2020-09-24 23:42     ` [Intel-gfx] " boris.ostrovsky
2020-09-24 23:42     ` boris.ostrovsky
2020-09-24 13:58 ` [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 23:43   ` boris.ostrovsky
2020-09-24 23:43     ` [Intel-gfx] " boris.ostrovsky
2020-09-24 23:43     ` boris.ostrovsky
2020-09-24 13:58 ` [PATCH 11/11] mm: remove alloc_vm_area Christoph Hellwig
2020-09-24 13:58   ` [Intel-gfx] " Christoph Hellwig
2020-09-24 15:09 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] mm: update the documentation for vfree Patchwork
2020-09-24 15:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-24 20:44 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-09-25 16:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] mm: update the documentation for vfree (rev2) Patchwork
2020-09-26  0:08 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-09-26  2:43 ` remove alloc_vm_area v2 Andrew Morton
2020-09-26  2:43   ` [Intel-gfx] " Andrew Morton
2020-09-26  2:43   ` Andrew Morton
2020-09-26  6:29   ` Christoph Hellwig
2020-09-26  6:29     ` [Intel-gfx] " Christoph Hellwig
2020-09-28 10:13     ` Joonas Lahtinen
2020-09-28 10:13       ` [Intel-gfx] " Joonas Lahtinen
2020-09-28 10:13       ` Joonas Lahtinen
2020-09-28 12:37       ` Christoph Hellwig
2020-09-28 12:37         ` [Intel-gfx] " Christoph Hellwig
2020-09-29 12:43         ` Joonas Lahtinen
2020-09-29 12:43           ` [Intel-gfx] " Joonas Lahtinen
2020-09-29 12:43           ` Joonas Lahtinen
2020-09-30 14:48           ` Christoph Hellwig
2020-09-30 14:48             ` [Intel-gfx] " Christoph Hellwig
2020-09-30 18:37             ` Daniel Vetter
2020-09-30 18:37               ` [Intel-gfx] " Daniel Vetter
2020-09-30 18:37               ` Daniel Vetter
2020-09-30 18:37               ` Daniel Vetter
2020-10-02 12:21 remove alloc_vm_area v4 Christoph Hellwig
2020-10-02 12:22 ` [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map Christoph Hellwig

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.