Re: 回复： Why QEMU translates one instruction to a TB？

["Alex Bennée" <alex.bennee@linaro.org>]

casmac <climber.cui@qq.com> writes:

> Hello , 
>
> &nbsp; thanks for the hints. I modified one parameter of&nbsp; memory_region_init_ram() call ,and the slow-path problem disappeared. 
>
> &nbsp; What I did is , change the RAM size from the exact memory size needed to hold the object file section(s), to the size that TI C3X user manual memory mapping specifies. 
>
> &nbsp; The former size is significantly smaller. But I did not specify the memory mapping else where in the program, so still unsure about the cause of conflict. 
>

Well you should be modelling the system - not what is actually loaded.

<snip>
> &gt; &nbsp; &nbsp; One intresting fact is that this somehow depends on the linker
> &gt; command file. The object file generated by the following linker command
> &gt; file(per_instr.lds)
> &gt; will "trigger" the problem. But QEMU work well with the object file
> &gt; linked by the other linker command file (ok.lds).
> &gt; &nbsp; &nbsp; What cause get_page_addr_code_hostp() function to return -1? I have
> &gt; no clue at all. Any advise is appreciated!!
>
> Maybe the "execute from small-MMU-region RAM" problem?
>
> See:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg549660.html

That is the change that introduced the ability to do this. On some SoCs
you often run small amounts of boot code from device memory (or on-chip
chache) while the main system memory is setup. Usually it's not a large
amount of code so doing it one instruction at a time isn't a massive
burden.

You have to do it this way because the underlying instruction may change
each time you read that memory. In normal system RAM we have
architectural hints such as flushing events which eventually end up as
tlb-flush events that ensure code is re-translated when needed.

-- 
Alex Bennée