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

Reply via email to