FAILED: patch "[PATCH] drm/i915: Don't use BAR mappings for ring buffers with LLC" failed to apply to 5.4-stable tree
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.... (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);
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.... (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);
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.... (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
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.... (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
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.... (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"?
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.... (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.
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.... (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
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.... (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
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.... (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.
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.... > (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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Greg KH -
gregkh＠linuxfoundation.org
-
Jason Andryuk -
John Harrison -
John.C.Harrison＠Intel.com