[libre-riscv-dev] Power memory fences and icache handling
Jacob Lifshay
programmerjake at gmail.com
Tue May 12 02:42:07 BST 2020
On Mon, May 11, 2020, 17:54 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:
> On Tuesday, May 12, 2020, Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> > > dcache:
> > > https://github.com/paulusmack/microwatt/blob/mmu/dcache.vhdl <
> > https://github.com/paulusmack/microwatt/blob/mmu/dcache.vhdl>
> > >
> > > icache:
> > > https://github.com/paulusmack/microwatt/blob/mmu/icache.vhdl <
> > https://github.com/paulusmack/microwatt/blob/mmu/icache.vhdl>
> >
> >
> > I was actually talking to Michael about that the other day.
> >
> > If you have an instruction that does a store to a location in the icache,
>
>
> that is prohibited by design.
>
If you're trying to run a standard Linux OS, writing to memory that could
be in the icache is required, that's how the dynamic linker works.
Additionally, loading code from disk (e.g. the exec() call) or JIT
compilation also requires writing to memory then executing it. In all of
those cases one or more icache invalidate and then an isync instruction (or
other context synchronizing instruction) are run before running the
modified code.
Note: it turns out that isync doesn't do any icache flushing without
additional icache invalidate instructions, so it's not quite as expensive
as I had originally thought for Power atomics, however, it still restarts
fetching and decoding instructions, so is still more expensive than
necessary for just using it as an atomic fence.
It's standard practice for JITs to map a section of memory with all of R/W
and execute permissions simultaneously, then, once a section of code is
written/modified, it will run the required icache invalidate and isync
instructions (RISC-V just uses a single fence.i instruction that must be
run on all harts using a syscall) before trying to execute the changed code.
Jacob
>
More information about the libre-riscv-dev
mailing list