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

[Peter Maydell]

On 30 April 2012 22:54, Emmanuel Blot <address@hidden> wrote:
> The platform is using an ARM7TDMI core with no cache.

Neat trick given QEMU doesn't support the 7TDMI :-) Have you added
that?

> 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).

I'm not sure what you mean by "replicated rather than created" here.
>From your description it's not clear whether the problem is an
out of date translation cache, because it sounds like the order
is "executing from one location, copy stuff into the SRAM; then
jump into the SRAM". Since we've not executed from SRAM before then
we won't have cached a duff translation...

> 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.

(If this was an ARMv7 core you'd be able to do the tb flush on an
ISB-with-MMU/cache-disabled, because the v7 architecture requires
at least an ISB.)

> 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.

Actually, 0x0 is a valid ARM insn (it's AND r0, r0, r0, which is
effectively a NOP). This suggests to me that what you think is
happening is perhaps not what is actually happening; maybe you
need to check a bit more closely?

> 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.

Yeah, this is because x86 has to cope with fairly arbitrary
self-modifying code... I guess the 7TDMI is kind of in the
same boat there (I think the only requirement is that you need
to do a jump or something that will flush the insn pipeline?);
but it's late and so I could be wrong on that.

-- PMM