Mikhail Tyutin <[email protected]> writes:
> Hi Alex,
>
>> > Exposing appropriate translation block flag allows plugins to
>> > handle "memory only" blocks in appropriate way.
>>
>> We don't want to expose internal details to the plugin. It shouldn't
>> need to care.
>>
>> Do you have a test case where you missed counting the execution of the
>> instruction?
>
> To speedup plugin execution time we want to shift processing logic to
> block translation phase and keep execution callback light. Also moving
> instrumentation at block level as opposite to instruction level, helps
> to speedup up execution as well.
The trouble is we don't guarantee that any given block will fully
execute every instruction. To be sure you capture every instruction you
need to instrument each one although as you point out this is expensive.
We do have counters although currently they are not atomic so can only
give a gross overview. There are plans to add a vCPU indexed score board
to solve that which will be a fairly lightweight instrumentation.
> Given that, we prepare structures in translation callback. For example:
>
> void handleBlockTranslation(qemu_plugin_id_t, qemu_plugin_tb* tblock)
> {
> BlockStats* s = new BlockStats();
> s->init(tblock);
> g_stats->append(s);
I guess this is a natural approach given we present a block translation
event but even without IO recompilation there will be multiple
translation blocks for any given set of addresses. We should make this
clearer in the documentation.
About the only thing you can be sure of is blocks won't cross page
boundaries (although I guess in future they may in linux-user).
>
> /* Then, insert execution callbacks and pass BlockStats as
> userdata for quick data lookup in run time at:
> 1) basic block prologue:
> qemu_plugin_register_vcpu_tb_exec_cb(tblock, cb, flags, s);
> 2) memory load/store:
> qemu_plugin_register_vcpu_mem_cb(tblock, cb, flags,
> mem_flags, s);
> */
> }
>
>
> Having artificial "mem only" block leads to allocation of new
> BlockStats and memory access will be attributed to that block instead
> of "original" one which is supposed to be executed. If we know that
> block is "mem only" on translation phase, then memory callback is
> implemented differently to find relevant BlockStats.
The alternative would be to have a page tracking structure based on the
qemu_plugin_insn_haddr of the instructions and aggregate your data
there.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro