?????? Why QEMU translates one instruction to a TB??

[casmac]

Hello ,

  thanks for the hints. I modified one parameter of  memory_region_init_ram() call ,and the slow-path problem disappeared.

  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.

  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.

            memory_region_init_ram(ary_sect_chain[i].mem_region, NULL, ary_sect_chain[i].s_name,
                                   /*ary_sect_chain[i].chain_size*4*/  ary_sect_chain[i].region_size,  &error_fatal);      //region_size is fixed as specified in CPU manual , region_size>chain_size*4

 

best regards,  

xiaolei

 

On 9/17/20 8:25 AM, casmac wrote:
> Hi all,
>      We try to add DSP architecure to QEMU 4.2. To load the COFF format
> object file, we have added loader code to load content from
>   the object file.
[...]

>     The COFF 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? I have
> 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