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