FAILED: patch "[PATCH] drm/i915: Don't use BAR mappings for ring buffers with LLC" failed to apply to 5.4-stable tree

FAILED: patch "[PATCH] drm/i915: Don't use BAR mappings for ring buffers with LLC" failed to apply to 5.4-stable tree

[gregkh]

The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x 85636167e3206c3fbd52254fc432991cc4e90194
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '167820543971229@kroah.com' --subject-prefix 'PATCH 5.4.y' HEAD^..

Possible dependencies:

85636167e320 ("drm/i915: Don't use BAR mappings for ring buffers with LLC")
fa85bfd19c26 ("drm/i915: Update the helper to set correct mapping")
e09e903a6e89 ("drm/i915/selftests: Prepare execlists and lrc selftests for obj->mm.lock removal")
17b7ab92bec3 ("drm/i915/selftests: Prepare hangcheck for obj->mm.lock removal")
d3ad29567d4e ("drm/i915/selftests: Prepare context selftest for obj->mm.lock removal")
c858ffa17716 ("drm/i915: Lock ww in ucode objects correctly")
c05258889ed4 ("drm/i915: Add igt_spinner_pin() to allow for ww locking around spinner.")
6895649bf13f ("drm/i915/selftests: Set error returns")
a0d3fdb628b8 ("drm/i915/gt: Split logical ring contexts from execlist submission")
d0d829e56674 ("drm/i915: split gen8+ flush and bb_start emission functions")
70a2b431c364 ("drm/i915/gt: Rename lrc.c to execlists_submission.c")
d33fcd798cb7 ("drm/i915/gt: Ignore dt==0 for reporting underflows")
09212e81e545 ("drm/i915/gt: Flush xcs before tgl breadcrumbs")
c10f6019d0b2 ("drm/i915/gt: Use the local HWSP offset during submission")
89db95377be4 ("drm/i915/gt: Confirm the context survives execution")
052e04f17056 ("drm/i915/selftests: Fix locking inversion in lrc selftest.")
47b086934f42 ("drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.")
3999a7087989 ("drm/i915: Rework intel_context pinning to do everything outside of pin_mutex")
2bf541ff6d06 ("drm/i915: Pin engine before pinning all objects, v5.")
b49a7d51c32e ("drm/i915: Nuke arguments to eb_pin_engine")

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 85636167e3206c3fbd52254fc432991cc4e90194 Mon Sep 17 00:00:00 2001
From: John Harrison <John.C.Harrison@Intel.com>
Date: Wed, 15 Feb 2023 17:11:01 -0800
Subject: [PATCH] drm/i915: Don't use BAR mappings for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
index fb1d2595392e..fb99143be98e 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ring, struct i915_gem_ww_ctx *ww)
 	if (unlikely(ret))
 		goto err_unpin;
 
-	if (i915_vma_is_map_and_fenceable(vma)) {
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
 		addr = (void __force *)i915_vma_pin_iomap(vma);
 	} else {
 		int type = i915_coherent_map_type(vma->vm->i915, vma->obj, false);
@@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring *ring)
 		return;
 
 	i915_vma_unset_ggtt_write(vma);
-	if (i915_vma_is_map_and_fenceable(vma))
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
 		i915_vma_unpin_iomap(vma);
 	else
 		i915_gem_object_unpin_map(vma->obj);

[Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index eee9fcbe0434..808269b2108f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1208,7 +1208,7 @@ int intel_ring_pin(struct intel_ring *ring)
 	if (unlikely(ret))
 		goto err_unpin;
 
-	if (i915_vma_is_map_and_fenceable(vma))
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
 		addr = (void __force *)i915_vma_pin_iomap(vma);
 	else
 		addr = i915_gem_object_pin_map(vma->obj,
@@ -1252,7 +1252,7 @@ void intel_ring_unpin(struct intel_ring *ring)
 	intel_ring_reset(ring, ring->emit);
 
 	i915_vma_unset_ggtt_write(vma);
-	if (i915_vma_is_map_and_fenceable(vma))
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
 		i915_vma_unpin_iomap(vma);
 	else
 		i915_gem_object_unpin_map(vma->obj);
-- 
2.39.1

[PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
---
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index eee9fcbe0434..808269b2108f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1208,7 +1208,7 @@ int intel_ring_pin(struct intel_ring *ring)
 	if (unlikely(ret))
 		goto err_unpin;
 
-	if (i915_vma_is_map_and_fenceable(vma))
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
 		addr = (void __force *)i915_vma_pin_iomap(vma);
 	else
 		addr = i915_gem_object_pin_map(vma->obj,
@@ -1252,7 +1252,7 @@ void intel_ring_unpin(struct intel_ring *ring)
 	intel_ring_reset(ring, ring->emit);
 
 	i915_vma_unset_ggtt_write(vma);
-	if (i915_vma_is_map_and_fenceable(vma))
+	if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
 		i915_vma_unpin_iomap(vma);
 	else
 		i915_gem_object_unpin_map(vma->obj);
-- 
2.39.1

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
> 
> Direction from hardware is that ring buffers should never be mapped
> via the BAR on systems with LLC. There are too many caching pitfalls
> due to the way BAR accesses are routed. So it is safest to just not
> use it.
> 
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v4.9+
> Tested-by: Jouni Högander <jouni.hogander@intel.com>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
>  drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Also queued up for 5.10.y, you forgot that one :)

thanks,

greg k-h

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
> 
> Direction from hardware is that ring buffers should never be mapped
> via the BAR on systems with LLC. There are too many caching pitfalls
> due to the way BAR accesses are routed. So it is safest to just not
> use it.
> 
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v4.9+
> Tested-by: Jouni Högander <jouni.hogander@intel.com>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
>  drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Also queued up for 5.10.y, you forgot that one :)

thanks,

greg k-h

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/15/2023 00:51, Greg KH wrote:
> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Direction from hardware is that ring buffers should never be mapped
>> via the BAR on systems with LLC. There are too many caching pitfalls
>> due to the way BAR accesses are routed. So it is safest to just not
>> use it.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: <stable@vger.kernel.org> # v4.9+
>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
> Also queued up for 5.10.y, you forgot that one :)
I'm still working through the backlog of them.

Note that these patches must all be applied as a pair. The 'don't use 
stolen' can be applied in isolation but won't totally fix the problem. 
However, applying 'don't use BAR mappings' without applying the stolen 
patch first will results in problems such as the failure to boot that 
was recently reported and resulted in a revert in one of the trees.

John.

>
> thanks,
>
> greg k-h

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/15/2023 00:51, Greg KH wrote:
> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Direction from hardware is that ring buffers should never be mapped
>> via the BAR on systems with LLC. There are too many caching pitfalls
>> due to the way BAR accesses are routed. So it is safest to just not
>> use it.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: <stable@vger.kernel.org> # v4.9+
>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
> Also queued up for 5.10.y, you forgot that one :)
I'm still working through the backlog of them.

Note that these patches must all be applied as a pair. The 'don't use 
stolen' can be applied in isolation but won't totally fix the problem. 
However, applying 'don't use BAR mappings' without applying the stolen 
patch first will results in problems such as the failure to boot that 
was recently reported and resulted in a revert in one of the trees.

John.

>
> thanks,
>
> greg k-h

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> On 3/15/2023 00:51, Greg KH wrote:
> > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > From: John Harrison <John.C.Harrison@Intel.com>
> > > 
> > > Direction from hardware is that ring buffers should never be mapped
> > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > due to the way BAR accesses are routed. So it is safest to just not
> > > use it.
> > > 
> > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: <stable@vger.kernel.org> # v4.9+
> > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > Also queued up for 5.10.y, you forgot that one :)
> I'm still working through the backlog of them.
> 
> Note that these patches must all be applied as a pair. The 'don't use
> stolen' can be applied in isolation but won't totally fix the problem.
> However, applying 'don't use BAR mappings' without applying the stolen patch
> first will results in problems such as the failure to boot that was recently
> reported and resulted in a revert in one of the trees.

I do not understand, you only submitted 1 patch here, what is the
"pair"?

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> On 3/15/2023 00:51, Greg KH wrote:
> > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > From: John Harrison <John.C.Harrison@Intel.com>
> > > 
> > > Direction from hardware is that ring buffers should never be mapped
> > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > due to the way BAR accesses are routed. So it is safest to just not
> > > use it.
> > > 
> > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: <stable@vger.kernel.org> # v4.9+
> > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > Also queued up for 5.10.y, you forgot that one :)
> I'm still working through the backlog of them.
> 
> Note that these patches must all be applied as a pair. The 'don't use
> stolen' can be applied in isolation but won't totally fix the problem.
> However, applying 'don't use BAR mappings' without applying the stolen patch
> first will results in problems such as the failure to boot that was recently
> reported and resulted in a revert in one of the trees.

I do not understand, you only submitted 1 patch here, what is the
"pair"?

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/15/2023 10:57, Greg KH wrote:
> On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
>> On 3/15/2023 00:51, Greg KH wrote:
>>> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>>
>>>> Direction from hardware is that ring buffers should never be mapped
>>>> via the BAR on systems with LLC. There are too many caching pitfalls
>>>> due to the way BAR accesses are routed. So it is safest to just not
>>>> use it.
>>>>
>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>> Cc: intel-gfx@lists.freedesktop.org
>>>> Cc: <stable@vger.kernel.org> # v4.9+
>>>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>>>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>> Also queued up for 5.10.y, you forgot that one :)
>> I'm still working through the backlog of them.
>>
>> Note that these patches must all be applied as a pair. The 'don't use
>> stolen' can be applied in isolation but won't totally fix the problem.
>> However, applying 'don't use BAR mappings' without applying the stolen patch
>> first will results in problems such as the failure to boot that was recently
>> reported and resulted in a revert in one of the trees.
> I do not understand, you only submitted 1 patch here, what is the
> "pair"?
The original patch series was two patches - 
https://patchwork.freedesktop.org/series/114080/. One to not use stolen 
memory and the other to not use BAR mappings. If the anti-BAR patch is 
applied without the anti-stolen patch then the i915 driver will attempt 
to access stolen memory directly which will fail. So both patches must 
be applied and in the correct order to fix the problem of cache aliasing 
when using BAR accesses on LLC systems.

As above, I am working my way through the bunch of 'FAILED patch' 
emails. The what-to-do instructions in those emails explicitly say to 
send the patch individually in reply to the 'FAILED' message rather than 
as part of any original series.

John.

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/15/2023 10:57, Greg KH wrote:
> On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
>> On 3/15/2023 00:51, Greg KH wrote:
>>> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>>
>>>> Direction from hardware is that ring buffers should never be mapped
>>>> via the BAR on systems with LLC. There are too many caching pitfalls
>>>> due to the way BAR accesses are routed. So it is safest to just not
>>>> use it.
>>>>
>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>> Cc: intel-gfx@lists.freedesktop.org
>>>> Cc: <stable@vger.kernel.org> # v4.9+
>>>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>>>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>> Also queued up for 5.10.y, you forgot that one :)
>> I'm still working through the backlog of them.
>>
>> Note that these patches must all be applied as a pair. The 'don't use
>> stolen' can be applied in isolation but won't totally fix the problem.
>> However, applying 'don't use BAR mappings' without applying the stolen patch
>> first will results in problems such as the failure to boot that was recently
>> reported and resulted in a revert in one of the trees.
> I do not understand, you only submitted 1 patch here, what is the
> "pair"?
The original patch series was two patches - 
https://patchwork.freedesktop.org/series/114080/. One to not use stolen 
memory and the other to not use BAR mappings. If the anti-BAR patch is 
applied without the anti-stolen patch then the i915 driver will attempt 
to access stolen memory directly which will fail. So both patches must 
be applied and in the correct order to fix the problem of cache aliasing 
when using BAR accesses on LLC systems.

As above, I am working my way through the bunch of 'FAILED patch' 
emails. The what-to-do instructions in those emails explicitly say to 
send the patch individually in reply to the 'FAILED' message rather than 
as part of any original series.

John.

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> On 3/15/2023 10:57, Greg KH wrote:
> > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > On 3/15/2023 00:51, Greg KH wrote:
> > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > 
> > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > use it.
> > > > > 
> > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > ---
> > > > >    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > Also queued up for 5.10.y, you forgot that one :)
> > > I'm still working through the backlog of them.
> > > 
> > > Note that these patches must all be applied as a pair. The 'don't use
> > > stolen' can be applied in isolation but won't totally fix the problem.
> > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > first will results in problems such as the failure to boot that was recently
> > > reported and resulted in a revert in one of the trees.
> > I do not understand, you only submitted 1 patch here, what is the
> > "pair"?
> The original patch series was two patches -
> https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> memory and the other to not use BAR mappings. If the anti-BAR patch is
> applied without the anti-stolen patch then the i915 driver will attempt to
> access stolen memory directly which will fail. So both patches must be
> applied and in the correct order to fix the problem of cache aliasing when
> using BAR accesses on LLC systems.
> 
> As above, I am working my way through the bunch of 'FAILED patch' emails.
> The what-to-do instructions in those emails explicitly say to send the patch
> individually in reply to the 'FAILED' message rather than as part of any
> original series.

So what commits exactly in Linus's tree should be in these stable
branches?  Sorry, I still do not understand if we are missing one or if
we need to revert something.

confused,

greg k-h

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> On 3/15/2023 10:57, Greg KH wrote:
> > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > On 3/15/2023 00:51, Greg KH wrote:
> > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > 
> > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > use it.
> > > > > 
> > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > ---
> > > > >    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > Also queued up for 5.10.y, you forgot that one :)
> > > I'm still working through the backlog of them.
> > > 
> > > Note that these patches must all be applied as a pair. The 'don't use
> > > stolen' can be applied in isolation but won't totally fix the problem.
> > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > first will results in problems such as the failure to boot that was recently
> > > reported and resulted in a revert in one of the trees.
> > I do not understand, you only submitted 1 patch here, what is the
> > "pair"?
> The original patch series was two patches -
> https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> memory and the other to not use BAR mappings. If the anti-BAR patch is
> applied without the anti-stolen patch then the i915 driver will attempt to
> access stolen memory directly which will fail. So both patches must be
> applied and in the correct order to fix the problem of cache aliasing when
> using BAR accesses on LLC systems.
> 
> As above, I am working my way through the bunch of 'FAILED patch' emails.
> The what-to-do instructions in those emails explicitly say to send the patch
> individually in reply to the 'FAILED' message rather than as part of any
> original series.

So what commits exactly in Linus's tree should be in these stable
branches?  Sorry, I still do not understand if we are missing one or if
we need to revert something.

confused,

greg k-h

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Jason Andryuk]

On Fri, Mar 17, 2023 at 8:58 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> > On 3/15/2023 10:57, Greg KH wrote:
> > > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > > On 3/15/2023 00:51, Greg KH wrote:
> > > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > >
> > > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > > use it.
> > > > > >
> > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > ---
> > > > > >    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > Also queued up for 5.10.y, you forgot that one :)
> > > > I'm still working through the backlog of them.
> > > >
> > > > Note that these patches must all be applied as a pair. The 'don't use
> > > > stolen' can be applied in isolation but won't totally fix the problem.
> > > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > > first will results in problems such as the failure to boot that was recently
> > > > reported and resulted in a revert in one of the trees.
> > > I do not understand, you only submitted 1 patch here, what is the
> > > "pair"?
> > The original patch series was two patches -
> > https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> > memory and the other to not use BAR mappings. If the anti-BAR patch is
> > applied without the anti-stolen patch then the i915 driver will attempt to
> > access stolen memory directly which will fail. So both patches must be
> > applied and in the correct order to fix the problem of cache aliasing when
> > using BAR accesses on LLC systems.
> >
> > As above, I am working my way through the bunch of 'FAILED patch' emails.
> > The what-to-do instructions in those emails explicitly say to send the patch
> > individually in reply to the 'FAILED' message rather than as part of any
> > original series.
>
> So what commits exactly in Linus's tree should be in these stable
> branches?  Sorry, I still do not understand if we are missing one or if
> we need to revert something.

Hi, Greg,

5.4.237 fails to boot as a Xen PV Dom0.  It hangs after modprobe
i915.ko with no further output, though it seems to response to magic
sysrq.

Reverting 5.4.y commit 1aed78cfda7f17f3cc71cb127a85a188eafc679a
("drm/i915: Don't use BAR mappings for ring buffers with LLC") lets it
boot properly.

Thanks,
Jason

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Jason Andryuk]

On Fri, Mar 17, 2023 at 8:58 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> > On 3/15/2023 10:57, Greg KH wrote:
> > > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > > On 3/15/2023 00:51, Greg KH wrote:
> > > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > >
> > > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > > use it.
> > > > > >
> > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > ---
> > > > > >    drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > > >    1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > Also queued up for 5.10.y, you forgot that one :)
> > > > I'm still working through the backlog of them.
> > > >
> > > > Note that these patches must all be applied as a pair. The 'don't use
> > > > stolen' can be applied in isolation but won't totally fix the problem.
> > > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > > first will results in problems such as the failure to boot that was recently
> > > > reported and resulted in a revert in one of the trees.
> > > I do not understand, you only submitted 1 patch here, what is the
> > > "pair"?
> > The original patch series was two patches -
> > https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> > memory and the other to not use BAR mappings. If the anti-BAR patch is
> > applied without the anti-stolen patch then the i915 driver will attempt to
> > access stolen memory directly which will fail. So both patches must be
> > applied and in the correct order to fix the problem of cache aliasing when
> > using BAR accesses on LLC systems.
> >
> > As above, I am working my way through the bunch of 'FAILED patch' emails.
> > The what-to-do instructions in those emails explicitly say to send the patch
> > individually in reply to the 'FAILED' message rather than as part of any
> > original series.
>
> So what commits exactly in Linus's tree should be in these stable
> branches?  Sorry, I still do not understand if we are missing one or if
> we need to revert something.

Hi, Greg,

5.4.237 fails to boot as a Xen PV Dom0.  It hangs after modprobe
i915.ko with no further output, though it seems to response to magic
sysrq.

Reverting 5.4.y commit 1aed78cfda7f17f3cc71cb127a85a188eafc679a
("drm/i915: Don't use BAR mappings for ring buffers with LLC") lets it
boot properly.

Thanks,
Jason

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/17/2023 05:58, Greg KH wrote:
> On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
>> On 3/15/2023 10:57, Greg KH wrote:
>>> On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
>>>> On 3/15/2023 00:51, Greg KH wrote:
>>>>> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>>>>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>>>>
>>>>>> Direction from hardware is that ring buffers should never be mapped
>>>>>> via the BAR on systems with LLC. There are too many caching pitfalls
>>>>>> due to the way BAR accesses are routed. So it is safest to just not
>>>>>> use it.
>>>>>>
>>>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>>> Cc: intel-gfx@lists.freedesktop.org
>>>>>> Cc: <stable@vger.kernel.org> # v4.9+
>>>>>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>>>>>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>>>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>>>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>>>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>> Also queued up for 5.10.y, you forgot that one :)
>>>> I'm still working through the backlog of them.
>>>>
>>>> Note that these patches must all be applied as a pair. The 'don't use
>>>> stolen' can be applied in isolation but won't totally fix the problem.
>>>> However, applying 'don't use BAR mappings' without applying the stolen patch
>>>> first will results in problems such as the failure to boot that was recently
>>>> reported and resulted in a revert in one of the trees.
>>> I do not understand, you only submitted 1 patch here, what is the
>>> "pair"?
>> The original patch series was two patches -
>> https://patchwork.freedesktop.org/series/114080/. One to not use stolen
>> memory and the other to not use BAR mappings. If the anti-BAR patch is
>> applied without the anti-stolen patch then the i915 driver will attempt to
>> access stolen memory directly which will fail. So both patches must be
>> applied and in the correct order to fix the problem of cache aliasing when
>> using BAR accesses on LLC systems.
>>
>> As above, I am working my way through the bunch of 'FAILED patch' emails.
>> The what-to-do instructions in those emails explicitly say to send the patch
>> individually in reply to the 'FAILED' message rather than as part of any
>> original series.
> So what commits exactly in Linus's tree should be in these stable
> branches?  Sorry, I still do not understand if we are missing one or if
> we need to revert something.
>
> confused,
>
> greg k-h
As far as I can tell, I have replied to all the "FAILED: patch" emails 
now. There should be a versions of these two patches available for all 
trees (being 4.14, 4.19, 5.4, 5.10 and 5.15):
     690e0ec8e63d drm/i915: Don't use stolen memory for ring buffers 
with LLC
     85636167e320 drm/i915: Don't use BAR mappings for ring buffers with LLC

They should be applied in the order of 'stolen memory' first and 'BAR 
mappings' second.

Thanks,
John.

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[John Harrison]

On 3/17/2023 05:58, Greg KH wrote:
> On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
>> On 3/15/2023 10:57, Greg KH wrote:
>>> On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
>>>> On 3/15/2023 00:51, Greg KH wrote:
>>>>> On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
>>>>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>>>>
>>>>>> Direction from hardware is that ring buffers should never be mapped
>>>>>> via the BAR on systems with LLC. There are too many caching pitfalls
>>>>>> due to the way BAR accesses are routed. So it is safest to just not
>>>>>> use it.
>>>>>>
>>>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>>> Cc: intel-gfx@lists.freedesktop.org
>>>>>> Cc: <stable@vger.kernel.org> # v4.9+
>>>>>> Tested-by: Jouni Högander <jouni.hogander@intel.com>
>>>>>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>>>> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
>>>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>>>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
>>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>> Also queued up for 5.10.y, you forgot that one :)
>>>> I'm still working through the backlog of them.
>>>>
>>>> Note that these patches must all be applied as a pair. The 'don't use
>>>> stolen' can be applied in isolation but won't totally fix the problem.
>>>> However, applying 'don't use BAR mappings' without applying the stolen patch
>>>> first will results in problems such as the failure to boot that was recently
>>>> reported and resulted in a revert in one of the trees.
>>> I do not understand, you only submitted 1 patch here, what is the
>>> "pair"?
>> The original patch series was two patches -
>> https://patchwork.freedesktop.org/series/114080/. One to not use stolen
>> memory and the other to not use BAR mappings. If the anti-BAR patch is
>> applied without the anti-stolen patch then the i915 driver will attempt to
>> access stolen memory directly which will fail. So both patches must be
>> applied and in the correct order to fix the problem of cache aliasing when
>> using BAR accesses on LLC systems.
>>
>> As above, I am working my way through the bunch of 'FAILED patch' emails.
>> The what-to-do instructions in those emails explicitly say to send the patch
>> individually in reply to the 'FAILED' message rather than as part of any
>> original series.
> So what commits exactly in Linus's tree should be in these stable
> branches?  Sorry, I still do not understand if we are missing one or if
> we need to revert something.
>
> confused,
>
> greg k-h
As far as I can tell, I have replied to all the "FAILED: patch" emails 
now. There should be a versions of these two patches available for all 
trees (being 4.14, 4.19, 5.4, 5.10 and 5.15):
     690e0ec8e63d drm/i915: Don't use stolen memory for ring buffers 
with LLC
     85636167e320 drm/i915: Don't use BAR mappings for ring buffers with LLC

They should be applied in the order of 'stolen memory' first and 'BAR 
mappings' second.

Thanks,
John.

Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Fri, Mar 17, 2023 at 09:07:50PM -0700, John Harrison wrote:
> On 3/17/2023 05:58, Greg KH wrote:
> > On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> > > On 3/15/2023 10:57, Greg KH wrote:
> > > > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > > > On 3/15/2023 00:51, Greg KH wrote:
> > > > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > 
> > > > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > > > use it.
> > > > > > > 
> > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > ---
> > > > > > >     drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > > > >     1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > Also queued up for 5.10.y, you forgot that one :)
> > > > > I'm still working through the backlog of them.
> > > > > 
> > > > > Note that these patches must all be applied as a pair. The 'don't use
> > > > > stolen' can be applied in isolation but won't totally fix the problem.
> > > > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > > > first will results in problems such as the failure to boot that was recently
> > > > > reported and resulted in a revert in one of the trees.
> > > > I do not understand, you only submitted 1 patch here, what is the
> > > > "pair"?
> > > The original patch series was two patches -
> > > https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> > > memory and the other to not use BAR mappings. If the anti-BAR patch is
> > > applied without the anti-stolen patch then the i915 driver will attempt to
> > > access stolen memory directly which will fail. So both patches must be
> > > applied and in the correct order to fix the problem of cache aliasing when
> > > using BAR accesses on LLC systems.
> > > 
> > > As above, I am working my way through the bunch of 'FAILED patch' emails.
> > > The what-to-do instructions in those emails explicitly say to send the patch
> > > individually in reply to the 'FAILED' message rather than as part of any
> > > original series.
> > So what commits exactly in Linus's tree should be in these stable
> > branches?  Sorry, I still do not understand if we are missing one or if
> > we need to revert something.
> > 
> > confused,
> > 
> > greg k-h
> As far as I can tell, I have replied to all the "FAILED: patch" emails now.
> There should be a versions of these two patches available for all trees
> (being 4.14, 4.19, 5.4, 5.10 and 5.15):
>     690e0ec8e63d drm/i915: Don't use stolen memory for ring buffers with LLC

Your backports of this are all now queued up, thanks.

greg k-h

Re: [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC

[Greg KH]

On Fri, Mar 17, 2023 at 09:07:50PM -0700, John Harrison wrote:
> On 3/17/2023 05:58, Greg KH wrote:
> > On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> > > On 3/15/2023 10:57, Greg KH wrote:
> > > > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > > > On 3/15/2023 00:51, Greg KH wrote:
> > > > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, John.C.Harrison@Intel.com wrote:
> > > > > > > From: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > 
> > > > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > > > use it.
> > > > > > > 
> > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > > > Cc: <stable@vger.kernel.org> # v4.9+
> > > > > > > Tested-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
> > > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > ---
> > > > > > >     drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > > > >     1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > Also queued up for 5.10.y, you forgot that one :)
> > > > > I'm still working through the backlog of them.
> > > > > 
> > > > > Note that these patches must all be applied as a pair. The 'don't use
> > > > > stolen' can be applied in isolation but won't totally fix the problem.
> > > > > However, applying 'don't use BAR mappings' without applying the stolen patch
> > > > > first will results in problems such as the failure to boot that was recently
> > > > > reported and resulted in a revert in one of the trees.
> > > > I do not understand, you only submitted 1 patch here, what is the
> > > > "pair"?
> > > The original patch series was two patches -
> > > https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> > > memory and the other to not use BAR mappings. If the anti-BAR patch is
> > > applied without the anti-stolen patch then the i915 driver will attempt to
> > > access stolen memory directly which will fail. So both patches must be
> > > applied and in the correct order to fix the problem of cache aliasing when
> > > using BAR accesses on LLC systems.
> > > 
> > > As above, I am working my way through the bunch of 'FAILED patch' emails.
> > > The what-to-do instructions in those emails explicitly say to send the patch
> > > individually in reply to the 'FAILED' message rather than as part of any
> > > original series.
> > So what commits exactly in Linus's tree should be in these stable
> > branches?  Sorry, I still do not understand if we are missing one or if
> > we need to revert something.
> > 
> > confused,
> > 
> > greg k-h
> As far as I can tell, I have replied to all the "FAILED: patch" emails now.
> There should be a versions of these two patches available for all trees
> (being 4.14, 4.19, 5.4, 5.10 and 5.15):
>     690e0ec8e63d drm/i915: Don't use stolen memory for ring buffers with LLC

Your backports of this are all now queued up, thanks.

greg k-h

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Don't use BAR mappings for ring buffers with LLC (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Don't use BAR mappings for ring buffers with LLC (rev3)
URL   : https://patchwork.freedesktop.org/series/115090/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/115090/revisions/3/mbox/ not applied
Applying: drm/i915: Don't use BAR mappings for ring buffers with LLC
Using index info to reconstruct a base tree...
A	drivers/gpu/drm/i915/gt/intel_ringbuffer.c
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): drivers/gpu/drm/i915/gt/intel_ringbuffer.c deleted in HEAD and modified in drm/i915: Don't use BAR mappings for ring buffers with LLC. Version drm/i915: Don't use BAR mappings for ring buffers with LLC of drivers/gpu/drm/i915/gt/intel_ringbuffer.c left in tree.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Don't use BAR mappings for ring buffers with LLC
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".