qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: "shocklink99@yahoo.com.tw" <shocklink99@yahoo.com.tw>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] How to precisely monitor all the memory references in QEMU to feed the cache model
Date: Sat, 27 Feb 2010 14:38:55 +0200	[thread overview]
Message-ID: <f43fc5581002270438n257c6864o1d923c54479df0fc@mail.gmail.com> (raw)
In-Reply-To: <408d4ad1002270408o7749a4e7u603a6e7bf6fdfc5f@mail.gmail.com>

On 2/27/10, shocklink99@yahoo.com.tw <shocklink99@yahoo.com.tw> wrote:
> Hi,
> I'm adding a cache model  into QEMU 0.12
> I have encountered a problem that the cache miss error rate was high
> compared to real platform Creator(arm926) .
> I used the QEMU integrator board to run the experiment.
>  I've modified
> softmmu_header.h
> softmmu_template.h
> target-arm/translate.c
>
> e.g. in softmmu_header.h
> glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong ptr)
> I monitored the ptr, I know that ptr is the access address
>
> e.g. in softmmu_template.h
> glue(glue(__ld, SUFFIX), MMUSUFFIX)(target_ulong addr
>
>
> e.g. target-arm/translate.c
> static inline TCGv gen_ld8s(TCGv addr, int index)
> {
>     TCGv tmp = new_tmp();
>
>      gen_helper_cache_access(addr , tcg_const_i32(1) );
>
>     tcg_gen_qemu_ld8s(tmp, addr, index);
>     return tmp;
> }
>
> I had taken care of all the related function.
> Is there  anything I ignored when running with the model?
>
> I have also reduce the timer interrupt to make it closed enough with the
> real platform.
> SO the context switch overhead should be little enough.

Interesting approach, this could be useful for modeling caches on
other architectures.

If your cache statistics merge I/D cache values, this could be one
source of error. I'd suppose pure data cache statistics should be
closer to reality, but QEMU's mode of operation for instruction
accesses differs a lot from real CPU:
 * on some architectures, translation may access some instructions in
the basic block which would not be executed by the CPU
 * we have a large TB cache, its size could be different from real CPU cache
 * TBs are flushed by QEMU (and that logic is different)
 * cache flushes by guest are ignored (this also applies to data caches)

      reply	other threads:[~2010-02-27 12:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27 12:08 [Qemu-devel] How to precisely monitor all the memory references in QEMU to feed the cache model shocklink99
2010-02-27 12:38 ` Blue Swirl [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=f43fc5581002270438n257c6864o1d923c54479df0fc@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shocklink99@yahoo.com.tw \
    /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).