[aarch64-port-dev ] ZeroTLAB and block zeroing

[Stuart Monteith]

The ARM ARM is quite explicit in the expectations for the behaviour of the
DC ZVA instruction. It should be considered as behaving as a series of
ordinary stores:

D3.4.9 Data cache zero instruction
> The DC ZVA instruction behaves as a set of stores to the location being
> accessed, and:
> • Generates a Permission fault if the translation regime being used when
> the instruction is executed does not permit writes to the locations.
> • Requires the same considerations for ordering and the management of
> coherency as any other store instruction.


In fact, it is stated as being different from most other cache operations.
Cache maintenance instructions should execute in program order relative to
once another, /except/ for DC ZVA.
If you are operating on the code cache and need a DC ZVA to be in order,
then you'll need a barrier.



>  D3.4 Cache support

Ordering and completion of data and instruction cache instructions



All data cache instructions, other than DC ZVA, that specify an address:
> • Execute in program order relative to loads or stores that access an
> address in Normal memory with either
> Inner Write Through or Inner Write Back attributes within the same cache
> line of minimum size, as indicated
> by CTR_EL0.DMinLine.
>   :         :          :

    etc..




On 26 October 2017 at 09:53, Andrew Haley <aph at redhat.com> wrote:
> On 25/10/17 23:55, Jasty, Ananth wrote:
>
>> Iirc the correctness was due to not firing enough barriers after the
>> zva. Throwing a dsb sy after the zeroes should be conservative until
>> we've found the proper ordering (1 dmb st should really cover
>> everything but we were young and naive back then).
>
> I'd love to see the justification for that.  There's no warning about
> DC ZVA needing magic barriers in the architecture spec.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671