Re: [Qemu-devel] On x86 MMU modes

[Sandhya Kumar]

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 <address@hidden> wrote:

On 3 June 2015 at 10:24, Sandhya Kumar <address@hidden> 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