[Qemu-devel] ARM target w/ self modifying code

[Emmanuel Blot]

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