1. 20 Aug, 2018 1 commit
  2. 17 Aug, 2018 3 commits
  3. 15 Aug, 2018 4 commits
  4. 13 Aug, 2018 6 commits
  5. 10 Aug, 2018 17 commits
  6. 09 Aug, 2018 1 commit
  7. 07 Aug, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat v2: Flush xlat tables after being modified · 3e318e40
      Antonio Nino Diaz authored
      During cold boot, the initial translation tables are created with data
      caches disabled, so all modifications go to memory directly. After the
      MMU is enabled and data cache is enabled, any modification to the tables
      goes to data cache, and eventually may get flushed to memory.
      
      If CPU0 modifies the tables while CPU1 is off, CPU0 will have the
      modified tables in its data cache. When CPU1 is powered on, the MMU is
      enabled, then it enables coherency, and then it enables the data cache.
      Until this is done, CPU1 isn't in coherency, and the translation tables
      it sees can be outdated if CPU0 still has some modified entries in its
      data cache.
      
      This can be a problem in some cases. For example, the warm boot code
      uses only the tables mapped during cold boot, which don't normally
      change. However, if they are modified (and a RO page is made RW, or a XN
      page is made executable) the CPU will see the old attributes and crash
      when it tries to access it.
      
      This doesn't happen ...
      3e318e40
  8. 06 Aug, 2018 4 commits
  9. 03 Aug, 2018 3 commits