Thanks Peter for your response. I notice that *tlb_fill()*  is happening
only in *softmmu_template.h *and not anywhere else in code base. This means
I should expect the TLB itself to be populated here for other code loads to
have successful look up later. Am I wrong with my understanding?

Even I guessed TLB to be fetching basic block (i.e. chunk of code with
single entry and exit), but realized its not and hence I posted the
question here. If we look at the sequence mentioned earlier in thread (i.e.
401bee , 401c07, 401c0e, 401c13)
401c07 and 401c0e forms a pattern - it is from the immediate value after
"mov" opcode, modRM bytes in lines 10, 11. I also checked other "mov"
lines. This pattern appears to match everywhere *expect* for the "mov" in
line 9 .

Let me know if you need more information.

[My executable]

0000000000401bee <_start>:
  401bee:       31 ed                   xor    %ebp,%ebp
  401bf0:       49 89 d1                mov    %rdx,%r9
  401bf3:       5e                      pop    %rsi
  401bf4:       48 89 e2                mov    %rsp,%rdx
  401bf7:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
  401bfb:       50                      push   %rax
  401bfc:       54                      push   %rsp
  401bfd:       49 c7 c0 20 24 40 00    mov    $0x402420,%r8
  // [Line 9]
  401c04:       48 c7 c1 90 23 40 00    mov    $0x402390,%rcx
// [Line 10]
  401c0b:       48 c7 c7 fe 1c 40 00    mov    $0x401cfe,%rdi
   // [Line 11]
  401c12:       e8 09 01 00 00          callq  401d20 <__libc_start_main>
  401c17:       f4                      hlt
  401c18:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
  401c1f:       00



On Sun, Jun 7, 2015 at 6:34 AM, Peter Maydell <peter.mayd...@linaro.org>
wrote:

> On 6 June 2015 at 08:36, Sandhya Kumar <insatiablecuriousit...@gmail.com>
> wrote:
> > Thanks Peter for your explanation.
> >
> > [The following question on TLB working could be a deviation from the
> first
> > mail here, but asking here instead of starting new thread.]
> >
> > I picked up a simple 'Hello world' ELF executable (shown at the end) and
> > tried to experiment with QEMU's address translations (i.e. guest VA ->
> host
> > VA in softmmu_template.h) occurring in userland for that process. This is
> > the sequence of guest VA (in hexadecimal) being translated:
> >
> > 401bee
> > 401c07
> > 401c0e
> > 401c13
> > 401d23
> > 401d39
> > 402009
> > ...... and so on
> >
> > The italized ones (first four) belong to _start of my executable and the
> > next few can be traced to __libc_start_main in my executable. Can anyone
> > please help me understand why the order is appearing like this?
>
> Most code loads don't go through the softmmu_template.h code. The
> frontend (target-*/translate.c) calls cpu_ld*_code functions, which
> are implemented by macros in include/exec/cpu_ldst_template.h. Those
> functions will try to do a direct lookup in QEMU's TLB first, and will
> only call the helper functions in softmmu_template.h if they miss.
> So you're not going to see a call for every instruction. (My guess is
> you're seeing one call every basic block, but it's not possible to tell
> from the detail you give.)
>
> -- PMM
>

Reply via email to