[Question] arm64: head: invalidating stale cache with mmu off

[Ard Biesheuvel]

On Tue, 17 Nov 2020 at 04:20, Jisheng Zhang <Jisheng.Zhang at 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.