Re: [Qemu-devel] The reason behind block linking constraint?

[Max Filippov]

> > I meant TLB change by e.g. tlb_set_page. If you change single page
> > mapping then all TBs in that page will be gone.
> > This may be the result of e.g. a page swapping, or a task switch.
> 
>   You said "all TBs in that page will be gone". Does it mean QEMU will
> invalidate those TBs by for example, tb_invalidate_phys_page_range? Or
> it just leave those TBs there (without executing them)? Because I don't
> see functions like tb_invalidate_phys_page_range are called after
> tlb_set_page, I am not sure what "gone" actually means.

Well, my explanation sucks. Let's say it other way, more precisely:
- you have two pieces of code in different pages, one of them jumps to the 
other;
- and you have two TBs, tb1 for the first piece and tb2 for the second;
- and you link them and there's direct jump from tb1 to tb2;
- now you change the mapping of the code page that contains second piece of 
code;
- after that there's another code (or no code at all) at the place where the 
second piece of code used to be;
- but the jump to tb2 still remains in tb1.

> > If there's no direct link between TBs then softmmu will be used during
> > the target TB search and softmmu will generate an appropriate guest
> > exception. See cpu_exec -> tb_find_fast -> tb_find_slow ->
> > get_page_addr_code.
> > 
> > But if there is a direct link, then softmmu has no chance to do it.
> 
>   Let me try to describe the flow. Correct me if I am wrong. Assume tb1
> and tb2 belong to different guest pages.
> 
>   If there's NO direct link between tb1 and tb2. After executing tb1,
> the control is transfered back to QEMU (cpu_exec), QEMU then call
> tb_find_fast to find the next TB, i.e., tb2.

Right.

>   I assume that "all TBs in that page will be gone" means QEMU will
> invalidate those TBs.

No, it won't. I had to say "all code in that page will be gone", sorry for the 
confusion.

> If not, I think tb_find_fast will return tb2 which should not be executed.

It won't either. tb_find_fast searches tb this way:

  tb = env->tb_jmp_cache[tb_jmp_cache_hash_func(pc)];

but 'page mapping change' implies TLB flush, at least for that page.
Both tlb_flush and tlb_flush_page will clear env->tb_jmp_cache and tb_find_fast 
will have to call tb_find_slow.

> So, tb_find_fast calls tb_find_slow,
> then tb_find_slow calls get_page_addr_code.
> 
>   get_page_addr_code return the guest physical address which
> corresponds to the pc (tb2). It looks up TLB (env1->tlb_table), and
> get a TLB miss since tlb_set_page has changed the mapping. 
> 
>   if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code !=
>                (addr & TARGET_PAGE_MASK))) {
>       ldub_code(addr);
>   }
> 
>   But I am not sure what happen after the TLB miss. You said the
> softmmu will generate a guest exception. Take x86 as an example,
> do you mean the raise_exception_err in tlb_fill?
> 
>   void tlb_fill(target_ulong addr, ...) {
>     ret = cpu_x86_handle_mmu_fault(env, addr, is_write, mmu_idx, 1);
>     if (ret) {
>         if (retaddr) {
>             }
>         }
>         raise_exception_err(env->exception_index, env->error_code);
>   }

Exactly. The exception will be raised inside the guest and the guest will 
execute its page fault handler or whatever.

Thanks.
-- Max