From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z18eM-0004iz-Nv for qemu-devel@nongnu.org; Sat, 06 Jun 2015 03:36:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z18eL-00056f-F5 for qemu-devel@nongnu.org; Sat, 06 Jun 2015 03:36:14 -0400 Received: from mail-ob0-x231.google.com ([2607:f8b0:4003:c01::231]:35083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z18eL-00056R-8K for qemu-devel@nongnu.org; Sat, 06 Jun 2015 03:36:13 -0400 Received: by obbgp2 with SMTP id gp2so46668418obb.2 for ; Sat, 06 Jun 2015 00:36:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <556EA649.3010805@redhat.com> <556EB3B8.2020402@redhat.com> <556EB956.1080301@redhat.com> Date: Sat, 6 Jun 2015 15:36:12 +0800 Message-ID: From: Sandhya Kumar Content-Type: multipart/alternative; boundary=001a11c32e068436ee0517d476c1 Subject: Re: [Qemu-devel] On x86 MMU modes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter.maydell@linaro.org Cc: Paolo Bonzini , qemu-devel@nongnu.org --001a11c32e068436ee0517d476c1 Content-Type: text/plain; charset=UTF-8 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 wrote: > On 3 June 2015 at 10:24, Sandhya Kumar > 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 > --001a11c32e068436ee0517d476c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 t= he 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 t= ranslated:

401bee
401c07
401c0e
401c13
401d23
401d39
402009 =C2=A0
...... and so on
<= div>
The italized ones (first four) belong to _star= t=C2=A0of my executable and the next few can be traced to __libc_sta= rt_main in my executable. Can anyone please help me understand w= hy the order is appearing like this?=C2=A0 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: =C2=A0 =C2=A0 file format elf64-x8= 6-64

Disassembly of section .text:
<= br>
0000000000401bee <_start>:
=C2=A0 401bee:= =C2=A0 =C2=A0 =C2=A0 31 ed =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 xor =C2=A0 =C2=A0%ebp,%ebp
=C2=A0 401bf0: = =C2=A0 =C2=A0 =C2=A0 49 89 d1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mov =C2=A0 =C2=A0%rdx,%r9
=C2=A0 401bf3: =C2=A0 =C2=A0 = =C2=A0 5e =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0pop =C2=A0 =C2=A0%rsi
=C2=A0 401bf4: =C2=A0 =C2=A0 = =C2=A0 48 89 e2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mov = =C2=A0 =C2=A0%rsp,%rdx
=C2=A0 401bf7: =C2=A0 =C2=A0 =C2=A0 48 83 = e4 f0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and =C2=A0 =C2=A0$0xfffffff= ffffffff0,%rsp

...... and so on


On Wed, Jun 3, 2015 at 5:36 PM, Peter Maydell <peter.ma= ydell@linaro.org> wrote:
On 3 June 2015 at 10:24, Sandhya Kumar <insatiablecuriousity07@gmail.com>= wrote:
> Well, I think we can also achieve this like adding a flag in the struc= ture
> 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

--001a11c32e068436ee0517d476c1--