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? Intuitively, I would guess to be as in every instruction of executable (401bee, 401bf0 etc). Also there was no context switch during the above which rules out TLB getting flushed at random time points. Let me know if you need more information. ./hello: file format elf64-x86-64 Disassembly of section .text: 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 ...... and so on On Wed, Jun 3, 2015 at 5:36 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 3 June 2015 at 10:24, Sandhya Kumar <insatiablecuriousit...@gmail.com> > wrote: > > Well, I think we can also achieve this like adding a flag in the > structure > > of CPUTLBEntry. > > Am I missing something? > > The point of the TLB data structure is to allow very fast access > in the common case of "TLB hit to guest RAM". If we had extra > flags to check in this code path it would slow it down. At the > moment the code only needs to look up the entry in the TLB > for the mmu_index it wants, and if it finds a hit it knows that > it is valid. > > -- PMM >
