qemu-devel
[Top][All Lists]
Advanced

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

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


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] (Resend) TranslationBlock annotation mechanism
Date: Thu, 28 Jan 2016 19:29:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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



reply via email to

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