4 ms·
Memcpying and executing code could also surface micro-architectural realities of the underlying CPU and memory subsystem micro-architecture that may need attent
by fork-bomber 5y ago
Memcpying and executing code could also surface micro-architectural realities of the underlying CPU and memory subsystem micro-architecture that may need attention from the programmer.
For example:
- On most RISCy Arm CPUs with Harvard style split instruction and data caches special architecture specific actions would need to be taken to ensure that after the memcpy any code still lingering in the data cache was cleaned/pushed out to the intended destination memory immediately (instead of at the next cache line eviction).
- Any stale code that happened to be cached from the destination (either by design or coincidence) needs to be invalidated in the instruction cache.
- Depending on the CPU micro architecture, programmer unknown speculative prefetching into caches as a result of the previous two actions may also need attention.
- oshiar53-0 5y agoIs there anything else that should be done except flushing D-cache and invalidating I-cache? I'm genuinely curious.
- jlokier 5y agoIf you are asking about general cases: If using paging you may need to invalidate the TLB entry which contains execute permission for the page. On x86 if using segments, after changing segment attributes you need to reload the segment selectors. The execution pipeline may need to be flushed, using a serialising instruction. When modifying code in place that may be being executed by another thread on another core at the same time, some modifications may trigger CPU errata. On particular CPUs there may be other kinds of caches or state invalidation required, but hopefully the OS provides a "flush I-cache" function that covers all of them.