On 02/10/2017 09:32 AM, Mark Rutland wrote:
Hi,
On Fri, Feb 03, 2017 at 02:22:48PM -0800, York Sun wrote:
We don't have to completely turn off MMU and cache to switch to another MMU table as far as the data is coherent before and after the switching. This patch relaxes the procedure.
Signed-off-by: York Sun york.sun@nxp.com CC: Alexander Graf agraf@suse.de
I found this issue while trying to change MMU table for a SPL boot. The RAM version U-Boot was copied to memory when d-cache was enabled. SPL code never flushed the cache (I will send another patch to fix that). With existing code, U-Boot stops running as soon as the MMU is diabled. With below propsed change, U-Boot continues to run. I have been in contact with ARM support and got very useful information. However, this switching TTBR method is "behavious that should work" but not well verified by ARM. During my debugging, I found other minor issue which convinced me this code wasn't exercised. I don't intend to use this method in long term, but figure it may help others by fixing it.
I believe the approach taken in this patch is unsafe.
Even if the resulting translations are identical across the old and new tables, it is not valid to transition from one set of tables to another unless:
(a) the mappings in both cases are non-global, and the ASID is switched, or:
(b) A Break-Before-Make strategy is followed to ensure that the TLBs contain no stale entries for the old tables.
Even if the resulting translations are identical, you can be subject to TLB conflict aborts and/or behaviours resulting from the amalgamation of TLB entries. In Linux, we had to write special code [1] to switch tables by using some trampoline code in the other TTBR.
I believe that in this case, you only need to clean the MMU-off code to the PoC (using DC DVAC), before temporarily turning the MMU off.
Thanks, Mark.
[1] https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr...
Thanks, Mark. Let's keep the current code. I will explore other ways to fix my issue.
York