This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Armv9 RME Cache access and GPC sequence order

I'm studying the Realm Management Extensions, and a question came to mind. The Arm ARM and other documentation (e.g., den0126) suggest that, conceptually, the GPC is performed before any memory access (including the caches). However, since cache lines are tagged with the associated PA, I imagine that this cache tag is used in coherency protocols as part of the snooped address. If so, imagine a hypothetical scenario where we are using different GPTs in two coherent cores with mutually exclusive regions marked as Normal and the rest of the PA marked as Root, both running in the Normal world. Could one of the cores access the other core's memory by fetching the data via the coherency bus if it were present in the other core cache (thus tagged as Normal) despite being marked as Root in its local GPT? Would the line be fetched but blocked by the GPC? If not, this would contradict my first observation. What behavior should I expect in future implementations? Can you point me to other documentation that would clear this up for me?

Note that I am perfectly aware that CCA was designed for a single shared GPT across all PEs. However, the spec seems to suggest that this is kind of implementation dependent (constrained unpredictable behavior which allows it in one of the variants). Also, I imagine we'll only likely find TLB entries with cached GPT information shared across PEs in SMT implementations.

Parents
  • Thanks for the detailed answer. But it raised another question in my mind:

    What you could potentially cause is corruption through incoherent access.  If PE A thinks the location is NS and PE B thinks the location is S, then caches lines with both PAs could exist independently in the system.  Which is going to be a problem when those lines get written back past the Point of Physical Aliasing (PoPA).

    Even if I guarantee no aliasing of physical addresses across the different GPTs, wouldn't cache invalidation instructions cause a similar issue? If in a tagged shared cache, a line belonging to PE A thus marked as normal could be invalidated by PE B running in the normal world, even if PE B's GPT would have that address marked as root or non-accessible. Or even just using an invalidation by set/way...

Reply
  • Thanks for the detailed answer. But it raised another question in my mind:

    What you could potentially cause is corruption through incoherent access.  If PE A thinks the location is NS and PE B thinks the location is S, then caches lines with both PAs could exist independently in the system.  Which is going to be a problem when those lines get written back past the Point of Physical Aliasing (PoPA).

    Even if I guarantee no aliasing of physical addresses across the different GPTs, wouldn't cache invalidation instructions cause a similar issue? If in a tagged shared cache, a line belonging to PE A thus marked as normal could be invalidated by PE B running in the normal world, even if PE B's GPT would have that address marked as root or non-accessible. Or even just using an invalidation by set/way...

Children