Re: Why QEMU treats each instruction as one translation block?

[Peter Maydell]

On Thu, 17 Sep 2020 at 07:11, casmac <climber.cui@qq.com> wrote:
>
>   The loader works functionally, but we then found that sometimes QEMU is 
> down-graded - it treats each instruction as one TB. In version 4.2,  
> debugging shows
> that get_page_addr_code_host() from accel/tcg/cputlb.c returns -1, as shown 
> below.
>
> accel/tcg/cputlb.c:
> tb_page_addr_t get_page_addr_code_hostp(CPUArchState *env, target_ulong addr,
>                                         void **hostp)
> {
>     uintptr_t mmu_idx = cpu_mmu_index(env, true);
>     uintptr_t index = tlb_index(env, mmu_idx, addr);
>     CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr);
>     void *p;
>
>     //.....
>     if (unlikely(entry->addr_code & TLB_MMIO)) {
>         /* The region is not backed by RAM.  */
>         if (hostp) {
>             *hostp = NULL;
>         }
>         return -1;        /* debugging falls to this branch, after this point 
> QEMU translate one instruction to a TB  */
>     }
>     //.......
> }
>     One intresting fact is that this somehow depends on the linker command 
> file. The object file generated by the following linker command 
> file(per_instr.lds)
> will "trigger" the problem. But QEMU work well with the object file linked by 
> the other linker command file (ok.lds).
>     What cause get_page_addr_code_hostp() function to return -1?

This happens when the code has been loaded to something that
is not "normal RAM" (eg it is a device). That is, if your
guest ELF file (or COFF file in your case) has headers saying
"load this code to address X", and address X isn't actually
RAM (or ROM, or a flash memory that's in read-mode), then
you'll get the slow-path. In normal usage this almost never
happens, because only weird ELF files (or ELF files that
were intended to be run on a completely different machine model)
try to load code to something other than RAM or ROM.

Exactly when this will happen will depend on the machine model
you're using and what devices and RAM it puts where in the
memory map. You should look at what address the code gets
loaded to and what is present at that address in the board
model you're using.

thanks
-- PMM