After some investigation on this, I found that even faking ctr_el0
content does not work. Indeed, "dc cvau" and "ic ivau" both are
privileged too (and fail with illegal instruction).
I started looking how other projects are handling this. In the case of
firefox js engine, they simply perform a FlushInstructionCache [1], and
nothing for data cache. From what I found on various websites, there is
no way to perform any data cache flush from userspace under Windows.
Out of curiosity, I looked in llvm how __builtin___clear_cache was
implemented, and for windows-arm64, it's simply a call to the same
function, FlushInstructionCache [2].
This explains why the generic implementation of flush_idcache_range does
the correct thing for this platform, and why tests I ran worked. Thus,
it's probably the best approach we can have for now.
[1]
https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/arm64/vixl/MozCpu-vixl.cpp#l110
[2]
https://github.com/llvm/llvm-project/blob/574e417460cdfebb8157fbe61b6a015e44856f64/compiler-rt/lib/builtins/clear_cache.c#L66
On 2/15/23 19:22, Richard Henderson wrote:
On 2/15/23 02:49, Pierrick Bouvier wrote:
I'm not an expert on this area, but I imagine that booting a full VM will force
TCG to
emit code at the same address twice (after having generated enough translated
blocks),
which shows that generic flush_idcache_range works. Is that reasoning correct?
Do you think we still need a specialized version for windows-arm64?
No, I don't think so. It would be ideal if we were able to read CTR_EL0,
because we make
use of the IDC field, but 0 is a safe default.
r~
