qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Brendan Dolan-Gavitt <brendandg@gatech.edu>
To: Christopher Covington <cov@codeaurora.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Wenjie Liu" <lwj0012@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Lluís Vilanova" <vilanova@ac.upc.edu>
Subject: Re: [Qemu-devel] About address mapping between host and guest in QEMU
Date: Fri, 24 Apr 2015 15:50:41 -0400	[thread overview]
Message-ID: <CAD2=zRD9oMv8FpZkNYbrCoU6FxwQ12=FsX4r7ELLFuaVj=5EJQ@mail.gmail.com> (raw)
In-Reply-To: <553A94F1.2020305@codeaurora.org>

One possible option that has come up in the past is disabling the TLB
for your testing. It is slower, though, and would only work on TCG,
not KVM.

The way I'm currently doing this is by changing the conditional jump
here to an absolute one inside of the TCG code generator for i386 (and
of course you can do something similar on other archs). The code here
has changed since I last looked at it, but this is roughly the place
to look:

https://github.com/qemu/qemu/blob/master/tcg/i386/tcg-target.c#L1222

Depending on your needs, you might want to also look at (shameless
plug) PANDA [1], which provides callbacks and a plugin architecture
for many things that happen in QEMU, including memory accesses. You
can see how we implement the memory callback here:

https://github.com/moyix/panda/blob/master/qemu/tcg/i386/tcg-target.c#L1079

Cheers,
Brendan

[1] https://github.com/moyix/panda

On Fri, Apr 24, 2015 at 3:09 PM, Christopher Covington
<cov@codeaurora.org> wrote:
> On 04/24/2015 08:46 AM, Peter Maydell wrote:
>> On 24 April 2015 at 12:26, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> On 24/04/2015 04:10, Wenjie Liu wrote:
>>>> The thing I am trying to achieve is to get the data and guest physical
>>>> address of every guest memory access, so I need to known which API can
>>>> be used to do the address transform.
>>>
>>> The short answer is that is difficult, because most guest memory
>>> accesses do not call any C function.  QEMU has a virtual TLB; if you
>>> have a TLB hit, the code generated by the JIT compiler does the conversion.
>>
>> In fact on a TLB hit it's possible that it's not actually any
>> longer determinable what the guest physical address was. This
>> only really happens with buggy guests, but if the guest does
>> a load that brings an entry into the TLB and then rewrites the
>> page table but fails to do the TLB maintenance operation, then
>> at the point when a subsequent load hits in the TLB we know
>> the guest virtual address and the host virtual address but not
>> the guest physical address, and we can't find the guest physaddr
>> any more even if we walk the page tables, because those have
>> been changed...
>>
>> Wanting to do this kind of memory access tracing is a pretty
>> common user request, though, and it would be nice if QEMU
>> had the facilities for it. It's just that our current design
>> is really not set up to make it easy to implement.
>
> While probably very slow, could the kind of guest memory trace in question be
> captured using the GDB stub and a breakpoint on every load an store
> instruction (or alternatively, a watchpoint on every possible address)?
>
> Chris
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

  reply	other threads:[~2015-04-24 19:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 13:31 [Qemu-devel] About address mapping between host and guest in QEMU Wenjie Liu
2015-04-22 15:26 ` Wenjie Liu
2015-04-23 13:56   ` Wenjie Liu
2015-04-23 14:03     ` Peter Maydell
2015-04-24  2:10       ` Wenjie Liu
2015-04-24 11:26         ` Paolo Bonzini
2015-04-24 12:46           ` Peter Maydell
2015-04-24 19:09             ` Christopher Covington
2015-04-24 19:50               ` Brendan Dolan-Gavitt [this message]
2015-04-24 23:48                 ` Christopher Covington
2015-04-25  1:51                   ` Wenjie Liu
2015-04-25 12:23                     ` Peter Maydell

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='CAD2=zRD9oMv8FpZkNYbrCoU6FxwQ12=FsX4r7ELLFuaVj=5EJQ@mail.gmail.com' \
    --to=brendandg@gatech.edu \
    --cc=cov@codeaurora.org \
    --cc=lwj0012@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=vilanova@ac.upc.edu \
    /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).