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

Is it necessary to flush data cache of a modified page table entry?

Dear experts,

  • Q0)  why can't MMU observe the table entry change made by its company core ?

working for Cortex-A55MP, EL1 in Aarch32, svc mode:

Both 2 level of table entry are attributed as (inner WB/WA, and outer WB/WA) and 
the MMU is set TTBR0 as (N=0, Inner WB WA , and Outer WB WA), 
is this not enough to have MMU to observe the page table entry change made by the same CPU core ?

If we add a DCCMVAC after modification of page entry, it works. Why ?

  • Q1) why it still have to take DCCMVAC, instead of  DCCMVAU ?

If a core is configured to work isolatedly, without shareability of these memory space to other cores.
And if it indeed have to flush data cache of modified page table entry, why it still have to take DCCMVAC, instead of  DCCMVAU ?
( Sure, it always fails for DCCMVAU applied after table entry modification.)

MMU access the same private/common cache layer with it CPU core, doesn't it ?

  • Q3) A-R-M seems not mention anything about this data cache flush of changing table entry.

From A-R-M of ARMv8-Cortex-A (DDI 0487D.a), the G.5.9  TLB maintenance requirements, 
we do not see any hint about the necessary to flush data cache of table entry.

The only one example for a uniprocessor system in G.5.9.1, there is no data cache flush operation.

Therefore, in a uniprocessor system, an example instruction sequence for writing a translation table entry, covering
changes to the instruction or data mappings is:

STR rx, [Translation table entry] ; write new entry to the translation table
DSB ; ensures visibility of the new entry
Invalidate TLB entry by VA (and ASID if non-global) [page address]
Invalidate BTC
DSB ; ensure completion of the Invalidate TLB instruction
ISB ; ensure table changes visible to instruction fetch

For SMP system, It neither not find anything about necessary of data cache flush operation.

All above mentions, I wonder the definition of  shareability domain of MMU and feel confused totally.

Parents
  • update:

    • About the Q0,
      I found my fault is coming from my mistakes on MMU.IRGN setting.

    1) Cortex-A55 only take " both Inner Write-Back Cacheable and Outer Write-Back Cacheable"  as cached.
    2) MMU.IRGN[1..0]  is composited from { bit0, bit6 } of TTBR0. I mis-spell the bit order and result as "Inner Write-through".

    After I correct the MMU.IRGN setting, it works without flushing data cache of modified page entry.

    • Thus, Q1 is also solved. Because MMU page walk is not non-cached, for wrong setting as "write-through".
Reply
  • update:

    • About the Q0,
      I found my fault is coming from my mistakes on MMU.IRGN setting.

    1) Cortex-A55 only take " both Inner Write-Back Cacheable and Outer Write-Back Cacheable"  as cached.
    2) MMU.IRGN[1..0]  is composited from { bit0, bit6 } of TTBR0. I mis-spell the bit order and result as "Inner Write-through".

    After I correct the MMU.IRGN setting, it works without flushing data cache of modified page entry.

    • Thus, Q1 is also solved. Because MMU page walk is not non-cached, for wrong setting as "write-through".
Children
No data