On 22 September 2016 23:27:41 BST, Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> wrote: >On 09/22/2016 03:13 PM, James Hogan wrote: >> well it'll do a protected dcache flush (i.e. using CACHEE with EVA). >Would kmap/kunmap or variants (fixed to work with aliasing dcache) be >able to take care of colouring / further flushing? > >We should flush kernel D-cache and user I-cache in any cache aliasing >system. I was wrong - a fixed HIGHMEM doesn't do any difference >actually, because page may be located in directly addressed memory (all > >HIGHMEM stuff is irrelevant in this case, kmap returns a lowmem >address). Maybe there'd need to be other flush calls too that do the right thing for aliasing. > >> >> In any case, simply changing to the user_ one is a no-op compared to >leaving as is where patch 9 would probably break it on EVA by making it >operate only on kernel addresses. > >EVA or not has no difference here - kernel address can still be a >different color to user address. i'm ignoring aliasing here. If the code doesn't already handle it then this patchset doesn't care. The goal is not to fix aliasing but to prevent any new breakage due to change in semantics in patch 9 to accommodate eva. EVA does make a difference if left as is, as flush_icache_range will operate on kernel addresses only after patch 9, so the cache op could literally not happen on the right address (irrespective of aliasing, and not a problem without eva). it also means the ops won't be protected, so failed page fault would i guess cause kernel oops instead of being ignored (maybe impossible to hit in this case, and definitely the exceptional rather than common case) > >And keeping kernel I-cache flush does break it really, not EVA. Right, but mainly because on eva user/kernel icache flushes will start to actually differ in what they do after patch 9 . -- James Hogan
