[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] How to precisely monitor all the memory references in

From: Blue Swirl
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

On 2/27/10, address@hidden <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]