Re: Why QEMU translates one instruction to a TB？

[Philippe Mathieu-Daudé]

On 9/17/20 8:25 AM, casmac wrote:
> Hi all,
> ?0?2?0?2 ?0?2 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
> ?0?2 the object file. 
[...]

> ?0?2 ?0?2 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,?0?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,
> ?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2
>  ?0?2 void **hostp)
> {
> ?0?2 ?0?2 uintptr_t mmu_idx = cpu_mmu_index(env, true);
> ?0?2 ?0?2 uintptr_t index = tlb_index(env, mmu_idx, addr);
> ?0?2 ?0?2 CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr);
> ?0?2 ?0?2 void *p;
> 
> ?0?2 ?0?2 //.....
> ?0?2 ?0?2 if (unlikely(entry->addr_code & TLB_MMIO)) {
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 /* The region is not backed by RAM.?0?2 */
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 if (hostp) {
> ?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2?0?2 ?0?2 *hostp = NULL;
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 }
> ?0?2?0?2?0?2?0?2?0?2 ?0?2 return -1;?0?2 ?0?2 ?0?2 ?0?2 /* debugging falls to 
> this branch, after this
> point QEMU translate one instruction to a TB?0?2 */
> ?0?2 ?0?2 }
> ?0?2 ?0?2 //.......
> }?0?2 ?0?2
> 
> ?0?2 ?0?2 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).
> ?0?2 ?0?2 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