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

Commit Message

John Harrison March 14, 2023, 2:22 a.m. UTC

From: John Harrison <[e-mail]>

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 <[e-mail]>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <[e-mail]>
Cc: Joonas Lahtinen <[e-mail]>
Cc: Jani Nikula <[e-mail]>
Cc: Rodrigo Vivi <[e-mail]>
Cc: Tvrtko Ursulin <[e-mail]>
Cc: [e-mail]
Cc: <[e-mail]> # v4.9+
Tested-by: Jouni Högander <[e-mail]>
Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <[e-mail]>
(cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
Signed-off-by: John Harrison <[e-mail]>
---
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Greg KH March 15, 2023, 7:51 a.m. UTC | #1

On Mon, Mar 13, 2023 at 07:22:11PM -0700, [e-mail] wrote:
> From: John Harrison <[e-mail]>
> 
> 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 <[e-mail]>
> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> Cc: Chris Wilson <[e-mail]>
> Cc: Joonas Lahtinen <[e-mail]>
> Cc: Jani Nikula <[e-mail]>
> Cc: Rodrigo Vivi <[e-mail]>
> Cc: Tvrtko Ursulin <[e-mail]>
> Cc: [e-mail]
> Cc: <[e-mail]> # v4.9+
> Tested-by: Jouni Högander <[e-mail]>
> Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
> Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> Signed-off-by: Jani Nikula <[e-mail]>
> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> Signed-off-by: John Harrison <[e-mail]>
> ---
>  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

John Harrison March 15, 2023, 5:07 p.m. UTC | #2

On 3/15/2023 00:51, Greg KH wrote:
> On Mon, Mar 13, 2023 at 07:22:11PM -0700, [e-mail] wrote:
>> From: John Harrison <[e-mail]>
>>
>> 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 <[e-mail]>
>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>> Cc: Chris Wilson <[e-mail]>
>> Cc: Joonas Lahtinen <[e-mail]>
>> Cc: Jani Nikula <[e-mail]>
>> Cc: Rodrigo Vivi <[e-mail]>
>> Cc: Tvrtko Ursulin <[e-mail]>
>> Cc: [e-mail]
>> Cc: <[e-mail]> # v4.9+
>> Tested-by: Jouni Högander <[e-mail]>
>> Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
>> Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>> Signed-off-by: Jani Nikula <[e-mail]>
>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>> Signed-off-by: John Harrison <[e-mail]>
>> ---
>>   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

Greg KH March 15, 2023, 5:57 p.m. UTC | #3

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, [e-mail] wrote:
> > > From: John Harrison <[e-mail]>
> > > 
> > > 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 <[e-mail]>
> > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > Cc: Chris Wilson <[e-mail]>
> > > Cc: Joonas Lahtinen <[e-mail]>
> > > Cc: Jani Nikula <[e-mail]>
> > > Cc: Rodrigo Vivi <[e-mail]>
> > > Cc: Tvrtko Ursulin <[e-mail]>
> > > Cc: [e-mail]
> > > Cc: <[e-mail]> # v4.9+
> > > Tested-by: Jouni Högander <[e-mail]>
> > > Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
> > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > Signed-off-by: Jani Nikula <[e-mail]>
> > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > Signed-off-by: John Harrison <[e-mail]>
> > > ---
> > >   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"?

John Harrison March 16, 2023, 8:58 p.m. UTC | #4

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, [e-mail] wrote:
>>>> From: John Harrison <[e-mail]>
>>>>
>>>> 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 <[e-mail]>
>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>> Cc: Chris Wilson <[e-mail]>
>>>> Cc: Joonas Lahtinen <[e-mail]>
>>>> Cc: Jani Nikula <[e-mail]>
>>>> Cc: Rodrigo Vivi <[e-mail]>
>>>> Cc: Tvrtko Ursulin <[e-mail]>
>>>> Cc: [e-mail]
>>>> Cc: <[e-mail]> # v4.9+
>>>> Tested-by: Jouni Högander <[e-mail]>
>>>> Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
>>>> Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>> Signed-off-by: Jani Nikula <[e-mail]>
>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>> Signed-off-by: John Harrison <[e-mail]>
>>>> ---
>>>>    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.

Greg Kroah-Hartman March 17, 2023, 12:58 p.m. UTC | #5

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, [e-mail] wrote:
> > > > > From: John Harrison <[e-mail]>
> > > > > 
> > > > > 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 <[e-mail]>
> > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > Cc: Chris Wilson <[e-mail]>
> > > > > Cc: Joonas Lahtinen <[e-mail]>
> > > > > Cc: Jani Nikula <[e-mail]>
> > > > > Cc: Rodrigo Vivi <[e-mail]>
> > > > > Cc: Tvrtko Ursulin <[e-mail]>
> > > > > Cc: [e-mail]
> > > > > Cc: <[e-mail]> # v4.9+
> > > > > Tested-by: Jouni Högander <[e-mail]>
> > > > > Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
> > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
> > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > Signed-off-by: Jani Nikula <[e-mail]>
> > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > Signed-off-by: John Harrison <[e-mail]>
> > > > > ---
> > > > >    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

Jason Andryuk March 17, 2023, 4:27 p.m. UTC | #6

On Fri, Mar 17, 2023 at 8:58 AM Greg KH <[e-mail]> 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, [e-mail] wrote:
> > > > > > From: John Harrison <[e-mail]>
> > > > > >
> > > > > > 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 <[e-mail]>
> > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > Cc: Chris Wilson <[e-mail]>
> > > > > > Cc: Joonas Lahtinen <[e-mail]>
> > > > > > Cc: Jani Nikula <[e-mail]>
> > > > > > Cc: Rodrigo Vivi <[e-mail]>
> > > > > > Cc: Tvrtko Ursulin <[e-mail]>
> > > > > > Cc: [e-mail]
> > > > > > Cc: <[e-mail]> # v4.9+
> > > > > > Tested-by: Jouni Högander <[e-mail]>
> > > > > > Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
> > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
> > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > Signed-off-by: Jani Nikula <[e-mail]>
> > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > Signed-off-by: John Harrison <[e-mail]>
> > > > > > ---
> > > > > >    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

John Harrison March 18, 2023, 4:07 a.m. UTC | #7

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, [e-mail] wrote:
>>>>>> From: John Harrison <[e-mail]>
>>>>>>
>>>>>> 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 <[e-mail]>
>>>>>> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
>>>>>> Cc: Chris Wilson <[e-mail]>
>>>>>> Cc: Joonas Lahtinen <[e-mail]>
>>>>>> Cc: Jani Nikula <[e-mail]>
>>>>>> Cc: Rodrigo Vivi <[e-mail]>
>>>>>> Cc: Tvrtko Ursulin <[e-mail]>
>>>>>> Cc: [e-mail]
>>>>>> Cc: <[e-mail]> # v4.9+
>>>>>> Tested-by: Jouni Högander <[e-mail]>
>>>>>> Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
>>>>>> Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
>>>>>> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
>>>>>> Signed-off-by: Jani Nikula <[e-mail]>
>>>>>> (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
>>>>>> Signed-off-by: John Harrison <[e-mail]>
>>>>>> ---
>>>>>>     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.

Greg Kroah-Hartman March 20, 2023, 1:28 p.m. UTC | #8

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, [e-mail] wrote:
> > > > > > > From: John Harrison <[e-mail]>
> > > > > > > 
> > > > > > > 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 <[e-mail]>
> > > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> > > > > > > Cc: Chris Wilson <[e-mail]>
> > > > > > > Cc: Joonas Lahtinen <[e-mail]>
> > > > > > > Cc: Jani Nikula <[e-mail]>
> > > > > > > Cc: Rodrigo Vivi <[e-mail]>
> > > > > > > Cc: Tvrtko Ursulin <[e-mail]>
> > > > > > > Cc: [e-mail]
> > > > > > > Cc: <[e-mail]> # v4.9+
> > > > > > > Tested-by: Jouni Högander <[e-mail]>
> > > > > > > Reviewed-by: Daniele Ceraolo Spurio <[e-mail]>
> > > > > > > Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]
> > > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > > Signed-off-by: Jani Nikula <[e-mail]>
> > > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > > Signed-off-by: John Harrison <[e-mail]>
> > > > > > > ---
> > > > > > >     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

Patch

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);