Re: [Qemu-devel] [RFC PATCH 0/3] (Resend) TranslationBlock annotation mechanism

[Peter Maydell]

On 14 January 2016 at 10:55, Peer Adelt <address@hidden> wrote:
> We have developed a generic concept to annotate TranslationBlocks during
> runtime. The initial idea was to use it for time annotation with data from
> static analysis tools. However, we have kept this approach as generic as
> possible to allow other kinds of annotation (e.g. power consumption, etc.).
>
> Our extension expects an XML file specifying the CFG of the program (similar
> to what you get from "gcc -ftree-dump-cfg")

(Do you mean -fdump-tree-cfg? But that gives rather different output format.)

> , where the edges are annotated
> with the data, that QEMU ought to accumulate during program execution. Each
> edge has a source and target context in which it is executed.
> For example: a for-loop that runs several times has its own context dependent
> edge for each iteration. We plan on making this more flexible by allowing
> to specify iterative context edges, i.e. from context n to context n+1.
>
> This approach is not limited to one target architecture but we only tested
> it for ARM and TriCore so far.
>
> To show the current state of this patch we have attached a very small example
> consisting of an ARM STM32F205 program and a timing annotation XML file (see
> reply to this letter). You can provide the XML file to QEMU with the
> "-annotation <XML-File>" option. During execution, the "value_sum" field of
> the CPUState data structure will accumulate a total value of 70 (cycles).
>
> Are there any comments? Is this in general a good idea to be added to upstream
> QEMU?

Firstly, apologies for not getting round to replying to this earlier.
(I was hoping somebody else might have a more informed view.)
I think this is interesting, but it has a couple of issues that make
it not really suitable for mainline:
 (1) it's a bit askew from what QEMU currently does -- we don't
really do much in the way of providing introspection into what the
guest is doing
 (2) it feels a bit unpolished at the moment (lack of documentation,
doesn't have any existing analysis tools that produce the format that
the code reads that would make it immediately usable by an end-user)

I think that a design that would likely get better traction here with
QEMU upstream would be one where you had tracepoints for relevant
events like "executing new TB", and some means of writing a plugin
to run code on those events, or perhaps just a post-analysis tool that
ran on the trace file. Then the code for reading XML and adding up the
relevant annotations would be confined to the plugin and wouldn't
necessarily need to be upstream at all.

However you should take that design suggestion with a considerable
pinch of salt, as I am very much not up to speed with the current
state of our tracing infrastructure.

thanks
-- PMM