Hi, I'm porting QEMU (1.0.x) to a new ARM based platform (qemu-system-arm on a x86/64 host)
The platform is using an ARM7TDMI core with no cache. Up to now everything was working fine, but I've recently bumped into an issue I have real hard time to solve: The native ARM code is replicating time-critical code (ISR mostly) at run time from a DRAM memory into a small faster SRAM memory of the physical device. The DRAM and SRAM physical devices are implemented as two distinct memory regions. The behavior is quite similar to self-modifying code [1], as new code is added into an uninitialized memory region (it is replicated rather than created). As there is no cache and no MMU on the platform, there is no explicit way to inform QEMU that new code has been updated in the SRAM memory region. It seems that this causes trouble to QEMU: the virtual ARM CPU triggers an undefined instruction exception the first time the ARM PC points to code that has been replicated in SRAM. Using the QEMU traces shows that QEMU thinks the memory region is initialized with zeroes rather than with the replicated code. The TCG generates host opcode for the ARM '0x0' instruction, which is not a valid ARM instruction. Looking at old QEMU documentation, it seems that x86 targets have solve this issue by flagging the TB memory pages as read/only [2], which allows to invalidate the TB cache whenever a page is overwritten with new code. I'm not sure if my analysis is correct, if the x86 hint is still in use, and if it is the best way to address this issue on cache-less, MMU-less ARM targets. I've spent some hours trying to understand the QEMU code on this topic, but I'm a bit confused right now. Any advice would be great, as well as specific function(s) to look at. Thanks, Manu [1] http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00556.html [2] http://static.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf