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

[Bastian Koppelmann]

Hi Fred,

On 01/28/2016 04:26 PM, Frederic Konrad wrote:
> Hi,
> 
> Is there a git tree with this series somewhere?
> Looks nice.
> 

here you go: https://github.com/bkoppelmann/tb-annotation.git

> Thanks,
> Fred
> 

Cheers,
Bastian

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

[Lluís Vilanova]

Lluís Vilanova writes:

> Bastian Koppelmann writes:
>> Hi Lluis,
>> On 01/27/2016 07:54 PM, Lluís Vilanova wrote:
[...]
>>> 
>>> So, I'd say that such support is on the list of current developments (at 
>>> least
>>> mine, specially now that I have a bit more time for it). But getting the 
>>> core
>>> infrastructure mainlined takes some time to ensure it makes sense and can be
>>> easily maintained and be generally usefull to vanilla QEMU.
>>> 

>> For us such a API would make a lot of sense and there is no benefit for
>> us to do our own API. Would it make sense for you if we helped you?

> Definitely. The instrumentation code needs some serious update to bring it
> up-to-date with the latest QEMU, but adding generally useful guest code 
> tracing
> events is something that can be easily pararellized.

FYI, I've rebased my local queue and pushed it to the public repository
[1]. Note that except for the head of the queue, patches are not tested (may not
even compile), but it's a first step at seriously rebooting the project.

I've also started splitting some of the series into separate branches to ease
their development in parallel (devel-*).

[1] https://projects.gso.ac.upc.edu/projects/qemu-dbi
https://code.gso.ac.upc.edu/git/qemu-dbi

PS: if you had a previous checkout, you might need to get it again (or do some
tedious checkout+rm+merge+checkout sequence), since I'm developing all these
series using stgit (which rewrites the story).


Cheers,
  Lluis

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

[Frederic Konrad]

Hi,

Is there a git tree with this series somewhere?
Looks nice.

Thanks,
Fred

On 14/01/2016 11:55, Peer Adelt wrote:
> Hey guys :)
>
> 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"), 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 " 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?
>
> All the best,
> Peer
>
> Peer Adelt (3):
>   tb-annotation: Added annotation XML file parser
>   tb-annotation: Add control flow graph mapper
>   tb-annotation: Activate annotation extension
>
>  Makefile |   5 +-
>  Makefile.objs|   4 +
>  Makefile.target  |   4 +-
>  configure|  13 ++
>  include/exec/gen-icount.h|  18 +++
>  include/qom/cpu.h|   9 ++
>  include/tb-annotation/tb-annotation-parser.h |  29 +
>  include/tb-annotation/tb-annotation.h|  64 ++
>  qemu-options.hx  |   8 ++
>  tb-annotation/Makefile.objs  |   1 +
>  tb-annotation/tb-annotation-parser.c | 174 
> +++
>  tcg-runtime.c|  99 +++
>  tcg/tcg-runtime.h|   4 +
>  vl.c |  25 
>  14 files changed, 454 insertions(+), 3 deletions(-)
>  create mode 100644 include/tb-annotation/tb-annotation-parser.h
>  create mode 100644 include/tb-annotation/tb-annotation.h
>  create mode 100644 tb-annotation/Makefile.objs
>  create mode 100644 tb-annotation/tb-annotation-parser.c
>

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

[Lluís Vilanova]

Bastian Koppelmann writes:

> Hi Lluis,
> On 01/27/2016 07:54 PM, Lluís Vilanova wrote:
>> There is this modified version I wrote [1], which precisely provides a plugin
>> infrastructure to attach callbacks into guest code events (a binary
>> instrumentation framework based on QEMU). At the time, the discussion 
>> resolved
>> that a full code instrumentation interface for plugins was too much code that
>> regular QEMU users & developers would not care about, easily leading to 
>> bitrot.
>> 

> This is too bad but looking at the discussion back then the
> argumentation is reasonable since an instrumentation API would and
> should touch everything in QEMU.

I tried (and I think succeeded) to keep the separation reasonably clean. The
main problem was adding public functions for plugins to peek/poke at guest state
and to inline additional TCG code, which would not be used anywhere else in
QEMU.


>> Instead, the list resolved (AFAIU) that it would be better to mainstream 
>> support
>> for guest code events, and make instrumentation an unofficial extension. I've
>> been (slowly) working to separate both pieces, making instrumentation a QEMU
>> patch that can be easily maintained out of tree.
>> 
>> The last patch series I sent sets the final stone on the core infrastructure 
>> for
>> the mainline part, just missing the patches I have queued to start adding 
>> guest
>> code trace events.

> Can you give me the name of the series.

This is it: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg02833.html


>> 
>> So, I'd say that such support is on the list of current developments (at 
>> least
>> mine, specially now that I have a bit more time for it). But getting the core
>> infrastructure mainlined takes some time to ensure it makes sense and can be
>> easily maintained and be generally usefull to vanilla QEMU.
>> 

> For us such a API would make a lot of sense and there is no benefit for
> us to do our own API. Would it make sense for you if we helped you?

Definitely. The instrumentation code needs some serious update to bring it
up-to-date with the latest QEMU, but adding generally useful guest code tracing
events is something that can be easily pararellized.

For one, my current implementation for instruction/bbl tracing modifies the main
disassembler loop on all targets. This can easily get out of sync as targets
evolve or new ones are added, so my plan was to refactor that into a common
disassembly loop with per-target hooks (since it's C, probably using ugly macros
like in softmmu_template.in).

Also, I never got to add meaningful events for CPU interrupts, for example.

As a side note, I wanted to write a paper about it once the interface stabilized
a bit more, but I haven't had time to implement some interesting/useful use
cases to accompany and motivate it (I've mainly used it to write ad-hoc analysis
tools for my PhD).

Cheers,
  Lluis

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

[Bastian Koppelmann]

Hi Lluis,

On 01/27/2016 07:54 PM, Lluís Vilanova wrote:
> There is this modified version I wrote [1], which precisely provides a plugin
> infrastructure to attach callbacks into guest code events (a binary
> instrumentation framework based on QEMU). At the time, the discussion resolved
> that a full code instrumentation interface for plugins was too much code that
> regular QEMU users & developers would not care about, easily leading to 
> bitrot.
> 

This is too bad but looking at the discussion back then the
argumentation is reasonable since an instrumentation API would and
should touch everything in QEMU.

> Instead, the list resolved (AFAIU) that it would be better to mainstream 
> support
> for guest code events, and make instrumentation an unofficial extension. I've
> been (slowly) working to separate both pieces, making instrumentation a QEMU
> patch that can be easily maintained out of tree.
> 
> The last patch series I sent sets the final stone on the core infrastructure 
> for
> the mainline part, just missing the patches I have queued to start adding 
> guest
> code trace events.

Can you give me the name of the series.

> 
> So, I'd say that such support is on the list of current developments (at least
> mine, specially now that I have a bit more time for it). But getting the core
> infrastructure mainlined takes some time to ensure it makes sense and can be
> easily maintained and be generally usefull to vanilla QEMU.
> 

For us such a API would make a lot of sense and there is no benefit for
us to do our own API. Would it make sense for you if we helped you?

Cheers,
Bastian

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

[Lluís Vilanova]

Bastian Koppelmann writes:

> Hi Peter,
> thank you for your feedback.

>> (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)
>> 
> Sure this is unpolished but we wanted to get feedback before we put too
> much work into it.

>> 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.
>> 

> We like your idea of a "plugin-api" that exposes hooks for relevant
> events since this is more generic than our approach. We came up with a
> list of relevant events for tracing:

> - pre-/post-execute_tb
> - pre-/post-translate_tb
> - pre-/post-interrupt
> (- memory access)

> These are the hooks that would be sufficient for our ideas for plugins.
> Do you have more suggestions for suitable hooks? Also, is there anything
> similar already in QEMU on which we could build on?

There is this modified version I wrote [1], which precisely provides a plugin
infrastructure to attach callbacks into guest code events (a binary
instrumentation framework based on QEMU). At the time, the discussion resolved
that a full code instrumentation interface for plugins was too much code that
regular QEMU users & developers would not care about, easily leading to bitrot.

Instead, the list resolved (AFAIU) that it would be better to mainstream support
for guest code events, and make instrumentation an unofficial extension. I've
been (slowly) working to separate both pieces, making instrumentation a QEMU
patch that can be easily maintained out of tree.

The last patch series I sent sets the final stone on the core infrastructure for
the mainline part, just missing the patches I have queued to start adding guest
code trace events.

So, I'd say that such support is on the list of current developments (at least
mine, specially now that I have a bit more time for it). But getting the core
infrastructure mainlined takes some time to ensure it makes sense and can be
easily maintained and be generally usefull to vanilla QEMU.


[1] https://projects.gso.ac.upc.edu/projects/qemu-dbi
The code is not up-to-date with the latest QEMU

Cheers,
  Lluis

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

[Bastian Koppelmann]

Hi Peter,

thank you for your feedback.

>  (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)
> 
Sure this is unpolished but we wanted to get feedback before we put too
much work into it.

> 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.
> 

We like your idea of a "plugin-api" that exposes hooks for relevant
events since this is more generic than our approach. We came up with a
list of relevant events for tracing:

- pre-/post-execute_tb
- pre-/post-translate_tb
- pre-/post-interrupt
(- memory access)

These are the hooks that would be sufficient for our ideas for plugins.
Do you have more suggestions for suitable hooks? Also, is there anything
similar already in QEMU on which we could build on?

> 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.

Who would I ask for the current state of tracing? Stefan?

Cheers,
Bastian

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

[Peter Maydell]

On 14 January 2016 at 10:55, Peer Adelt  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 " 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

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

[Peer Adelt]

On 14.01.2016 11:55, Peer Adelt wrote:

Hey guys :)

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"), 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 " 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?

All the best,
Peer

Peer Adelt (3):
   tb-annotation: Added annotation XML file parser
   tb-annotation: Add control flow graph mapper
   tb-annotation: Activate annotation extension

  Makefile |   5 +-
  Makefile.objs|   4 +
  Makefile.target  |   4 +-
  configure|  13 ++
  include/exec/gen-icount.h|  18 +++
  include/qom/cpu.h|   9 ++
  include/tb-annotation/tb-annotation-parser.h |  29 +
  include/tb-annotation/tb-annotation.h|  64 ++
  qemu-options.hx  |   8 ++
  tb-annotation/Makefile.objs  |   1 +
  tb-annotation/tb-annotation-parser.c | 174 +++
  tcg-runtime.c|  99 +++
  tcg/tcg-runtime.h|   4 +
  vl.c |  25 
  14 files changed, 454 insertions(+), 3 deletions(-)
  create mode 100644 include/tb-annotation/tb-annotation-parser.h
  create mode 100644 include/tb-annotation/tb-annotation.h
  create mode 100644 tb-annotation/Makefile.objs
  create mode 100644 tb-annotation/tb-annotation-parser.c


See attachment


annotation-example-project.tar.bz2
Description: application/bzip

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

[Peer Adelt]

Hey guys :)

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"), 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 " 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?

All the best,
Peer

Peer Adelt (3):
  tb-annotation: Added annotation XML file parser
  tb-annotation: Add control flow graph mapper
  tb-annotation: Activate annotation extension

 Makefile |   5 +-
 Makefile.objs|   4 +
 Makefile.target  |   4 +-
 configure|  13 ++
 include/exec/gen-icount.h|  18 +++
 include/qom/cpu.h|   9 ++
 include/tb-annotation/tb-annotation-parser.h |  29 +
 include/tb-annotation/tb-annotation.h|  64 ++
 qemu-options.hx  |   8 ++
 tb-annotation/Makefile.objs  |   1 +
 tb-annotation/tb-annotation-parser.c | 174 +++
 tcg-runtime.c|  99 +++
 tcg/tcg-runtime.h|   4 +
 vl.c |  25 
 14 files changed, 454 insertions(+), 3 deletions(-)
 create mode 100644 include/tb-annotation/tb-annotation-parser.h
 create mode 100644 include/tb-annotation/tb-annotation.h
 create mode 100644 tb-annotation/Makefile.objs
 create mode 100644 tb-annotation/tb-annotation-parser.c

-- 
2.5.0