FYI: differences in FreeBSD's code vs.: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABJDBHI.html and its "Example 11.5. Cleaning by Virtual Address". . . (I do not claim to know that the differences point to any error. But I note them in case they prompt something. A couple of points do seem odd to me for the FreeBSD code.) The ARM example code does: <Data clean loop with DC CAVU (no DSB ISH)> DSB ISH <Instruction Clean(invalidate) loop with IC IVAU (no DSB ISH or ISB)> DSB ISH ISB This has the property of forcing visibility only after everything is available to be visible (DSB ISH being referenced here). (The FreeBSD code does not have this property, but enforces visibility of a mix of old and new as it goes along.) It is point-of-unification code (data and instruction) for its purpose. The FreeBSD arm64_dcache_<?>_range code always pairs: DC CAVAC (or CIVAC or IVAC) DSB ISH inside it loop, forcing visibility of its intermediate state as it goes along. It is also point-of-coherency instead of point of unification (because of its purpose). The FreeBSD arm64_idcache_wbinv_range code always does the sequence of 4: DC CIVAC DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is is a mix of point-of-coherency and point of unification code that forces visibility (DSB ISH) as it goes along, not just after the overall loop. To me the mix of point-of-coherency and point-of-unification seems strange. The FreeBSD arm64_icache_sync_range code always does the sequence of 4: DC CIVAU DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is the closest to the "Example 11.5. Cleaning by Virtual Address" code and its purpose. It is all point-of-unification code that forces visibility (DSB ISH) as it goes long, not just after the overall loop. === Mark Millard markmi at dsl-only.netReceived on Wed May 03 2017 - 02:13:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC