[U-Boot] [RFC PATCH] armv8: cache: Switch MMU table without turning off MMU

[york sun]

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 at nxp.com>
>> CC: Alexander Graf <agraf at 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.infradead.org%2Fpipermail%2Flinux-arm-kernel%2F2016-January%2F401434.html&data=01%7C01%7Cyork.sun%40nxp.com%7C12db759ec0a846ebf27308d451dad8ec%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=0gKNRAMUSKKuBAGYAmQOLtW8EOk1e6FOk9VZn50hYg8%3D&reserved=0
>

Thanks, Mark. Let's keep the current code. I will explore other ways to 
fix my issue.

York