qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: malc <av1474@comtv.ru>
To: Jun Koi <junkoi2004@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Monitoring memory access
Date: Fri, 9 Jul 2010 22:44:22 +0400 (MSD)	[thread overview]
Message-ID: <alpine.LNX.2.00.1007092238290.1413@linmac> (raw)
In-Reply-To: <AANLkTikDZCEpZg17vxkUHI8T92YRz6RotG43kkpqDw6A@mail.gmail.com>

On Fri, 9 Jul 2010, Jun Koi wrote:

> On Fri, Jul 9, 2010 at 7:41 PM, malc <av1474@comtv.ru> wrote:
> > On Fri, 9 Jul 2010, Jun Koi wrote:
> >
> >> Hi,
> >>
> >> I want to monitor memory reading access in Qemu. According to function
> >> tcg/i386/tcg-target.c::tcg_out_qemu_ld(), all the memory access must
> >> call qemu_ld_helpers[] functions, which in turn calls __ldX_mmu
> >> functions.
> >>
> >> These __ldX_mmu() functions are declared in softmmu_template.c, with
> >> macro glue(glue(__ld, SUFFIX), MMUSUFFIX).
> >>
> >> To monitor memory reading access, I simply put my monitored code at
> >> the top of the above macro. But apparently I still miss something,
> >> because I dont see the memory access I am looking for.
> >>
> >> Any hint where I am wrong? Perhaps some memory access do not call the
> >> qemu_ld_helpers[] functions?
> >
> > Haven't we been through this already?
> > http://www.mail-archive.com/qemu-devel@nongnu.org/msg29788.html
> >
> 
> Yes, we did, but sorry I am still stuck there.
> 
> You said that once TLB is setup properly, future memory access would
> do directly, without going thru helpers any more. Is that correct?

Once TLB is filled helpers will be bypassed yes.

> 
> But what I see in tcg_out_qemu_ld() is that the below function is always 
> called:
> 
> ....
>     tcg_out_calli(s, (tcg_target_long)qemu_ld_helpers[s_bits]);
> ....

Even if you are looking only on, say, tcg/i386/tcg-target.c you should
notice that the function does a lot more than just ld_helpers call -
testing tlb and jumping around...

> And since qemu_ld_helpers[] points to __ldX_mmu, so that means below
> macro is always executed:
> 
> glue(glue(__ld, SUFFIX), MMUSUFFIX).
>
> I simply put my monitored code inside this macro.
> 
> Could you give me some hints where I am wrong?
> 

I have honestly nothing more to add, just look closer.

-- 
mailto:av1474@comtv.ru

      reply	other threads:[~2010-07-09 18:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-09  9:55 [Qemu-devel] Monitoring memory access Jun Koi
2010-07-09 10:41 ` malc
2010-07-09 12:45   ` Jun Koi
2010-07-09 18:44     ` malc [this message]

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=alpine.LNX.2.00.1007092238290.1413@linmac \
    --to=av1474@comtv.ru \
    --cc=junkoi2004@gmail.com \
    --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).