From: Sandhya Kumar <insatiablecuriousity07@gmail.com>
To: peter.maydell@linaro.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] On x86 MMU modes
Date: Sat, 6 Jun 2015 15:36:12 +0800 [thread overview]
Message-ID: <CAEqbB47L1MqJQ7PwPS3OWUY+bAj0X8SQbNkTZsfrdsQUDJQnYQ@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA9BHxh13gVOj-y0CN3EHcHNgdTw6iSnFi+=PAtC4D7CWQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
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.maydell@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
> 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
>
[-- Attachment #2: Type: text/html, Size: 3027 bytes --]
next prev parent reply other threads:[~2015-06-06 7:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 6:51 [Qemu-devel] On x86 MMU modes Sandhya Kumar
2015-06-03 7:01 ` Paolo Bonzini
2015-06-03 7:41 ` Sandhya Kumar
2015-06-03 7:58 ` Paolo Bonzini
2015-06-03 8:07 ` Sandhya Kumar
2015-06-03 8:22 ` Paolo Bonzini
2015-06-03 9:24 ` Sandhya Kumar
2015-06-03 9:36 ` Peter Maydell
2015-06-06 7:36 ` Sandhya Kumar [this message]
2015-06-06 22:34 ` Peter Maydell
2015-06-08 2:51 ` Sandhya Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEqbB47L1MqJQ7PwPS3OWUY+bAj0X8SQbNkTZsfrdsQUDJQnYQ@mail.gmail.com \
--to=insatiablecuriousity07@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).