linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [Question] arm64: head: invalidating stale cache with mmu off
@ 2020-11-17  0:52 Wonhyuk Yang
  2020-11-17  3:18 ` Jisheng Zhang
  0 siblings, 1 reply; 3+ messages in thread
From: Wonhyuk Yang @ 2020-11-17  0:52 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Catalin Marinas, Will Deacon

Hi, I have a question about dmb barriers in arm64's head.S.
In the head.S, I could see the pattern below several times.

str w0, [x1]
dmb sys
dc ivac, x1   // Invalidate potentially stale cache line

I found that,
arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag
commit: d0488597a1b71
explained this code.

> This patch reworks the broken flushing code so that we:
>
> (1) Use a DMB to order the strongly-ordered write of the cacheline
> against the subsequent cache-maintenance operation (by-VA
> operations only hazard against normal, cacheable accesses).
>
> (2) Use a single dc ivac instruction to invalidate any clean lines
> containing a stale copy of the line after it has been updated.
> Use a DMB to order the strongly-> ordered write of the cacheline

But I still don't  understand why the store operation should precede the
dc operation.

Is there any problem, if the dc operation precedes the store operation?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [Question] arm64: head: invalidating stale cache with mmu off
  2020-11-17  0:52 [Question] arm64: head: invalidating stale cache with mmu off Wonhyuk Yang
@ 2020-11-17  3:18 ` Jisheng Zhang
  2020-11-17  8:53   ` Ard Biesheuvel
  0 siblings, 1 reply; 3+ messages in thread
From: Jisheng Zhang @ 2020-11-17  3:18 UTC (permalink / raw)
  To: Wonhyuk Yang; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel

On Tue, 17 Nov 2020 09:52:10 +0900 Wonhyuk Yang wrote:


> 
> 
> Hi, I have a question about dmb barriers in arm64's head.S.
> In the head.S, I could see the pattern below several times.
> 
> str w0, [x1]
> dmb sys
> dc ivac, x1   // Invalidate potentially stale cache line
> 
> I found that,
> arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag
> commit: d0488597a1b71
> explained this code.
> 
> > This patch reworks the broken flushing code so that we:
> >
> > (1) Use a DMB to order the strongly-ordered write of the cacheline
> > against the subsequent cache-maintenance operation (by-VA
> > operations only hazard against normal, cacheable accesses).
> >
> > (2) Use a single dc ivac instruction to invalidate any clean lines
> > containing a stale copy of the line after it has been updated.
> > Use a DMB to order the strongly-> ordered write of the cacheline  
> 
> But I still don't  understand why the store operation should precede the
> dc operation.
> 
> Is there any problem, if the dc operation precedes the store operation?
> 

Just my opinion:
If dc op precedes the store, speculatively fetch of system cache or arch
cache for guest os after the dc could still bring coherence problems when
the var is checked later. I.E consider below sequence:

dc ivac

speculatively fetch of system cache or arch cache for guest os

str	w20, [x1]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [Question] arm64: head: invalidating stale cache with mmu off
  2020-11-17  3:18 ` Jisheng Zhang
@ 2020-11-17  8:53   ` Ard Biesheuvel
  0 siblings, 0 replies; 3+ messages in thread
From: Ard Biesheuvel @ 2020-11-17  8:53 UTC (permalink / raw)
  To: Jisheng Zhang
  Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, Wonhyuk Yang

On Tue, 17 Nov 2020 at 04:20, Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>
> On Tue, 17 Nov 2020 09:52:10 +0900 Wonhyuk Yang wrote:
>
>
> >
> >
> > Hi, I have a question about dmb barriers in arm64's head.S.
> > In the head.S, I could see the pattern below several times.
> >
> > str w0, [x1]
> > dmb sys
> > dc ivac, x1   // Invalidate potentially stale cache line
> >
> > I found that,
> > arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag
> > commit: d0488597a1b71
> > explained this code.
> >
> > > This patch reworks the broken flushing code so that we:
> > >
> > > (1) Use a DMB to order the strongly-ordered write of the cacheline
> > > against the subsequent cache-maintenance operation (by-VA
> > > operations only hazard against normal, cacheable accesses).
> > >
> > > (2) Use a single dc ivac instruction to invalidate any clean lines
> > > containing a stale copy of the line after it has been updated.
> > > Use a DMB to order the strongly-> ordered write of the cacheline
> >
> > But I still don't  understand why the store operation should precede the
> > dc operation.
> >
> > Is there any problem, if the dc operation precedes the store operation?
> >
>
> Just my opinion:
> If dc op precedes the store, speculatively fetch of system cache or arch
> cache for guest os after the dc could still bring coherence problems when
> the var is checked later. I.E consider below sequence:
>
> dc ivac
>
> speculatively fetch of system cache or arch cache for guest os
>
> str     w20, [x1]
>

Indeed. Remember that the store is going straight to memory, and we
don't want the location to be shadowed by stale, clean cachelines.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

end of thread, other threads:[~2020-11-17  8:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17  0:52 [Question] arm64: head: invalidating stale cache with mmu off Wonhyuk Yang
2020-11-17  3:18 ` Jisheng Zhang
2020-11-17  8:53   ` Ard Biesheuvel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).