• Jeffrey Lee's avatar
    Make MMU_Changing ARMops perform the sub-operations in a sensible order · 9a96263a
    Jeffrey Lee authored
    Detail:
      For a while we've known that the correct way of doing cache maintenance on ARMv6+ (e.g. when converting a page from cacheable to non-cacheable) is as follows:
      1. Write new page table entry
      2. Flush old entry from TLB
      3. Clean cache + drain write buffer
      The MMU_Changing ARMops (e.g. MMU_ChangingEntry) implement the last two items, but in the wrong order. This has caused the operations to fall out of favour and cease to be used, even in pre-ARMv6 code paths where the effects of improper cache/TLB management perhaps weren't as readily visible.
      This change re-specifies the relevant ARMops so that they perform their sub-operations in the correct order to make them useful on modern ARMs, updates the implementations, and updates the kernel to make use of the ops whereever relevant.
      File changes:
      - Docs/HAL/ARMop_API - Re-specify all the MMU_Changing ARMops to state that they are for use just after a page table entry has been changed (as opposed to before - e.g. 5.00 kernel behaviour). Re-specify the cacheable ones to state that the TLB invalidatation comes first.
      - s/ARM600, s/ChangeDyn, s/HAL, s/MemInfo, s/VMSAv6, s/AMBControl/memmap - Replace MMU_ChangingUncached + Cache_CleanInvalidate pairs with equivalent MMU_Changing op
      - s/ARMops - Update ARMop implementations to do everything in the correct order
      - s/MemMap2 - Update ARMop usage, and get rid of some lingering sledgehammer logic from ShuffleDoublyMappedRegionForGrow
    Admin:
      Tested on pretty much everything currently supported
    
    
    Version 5.70. Tagged as 'Kernel-5_70'
    9a96263a
VMSAv6 25.7 KB