qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrument


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation
Date: Fri, 15 Sep 2017 16:45:42 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Peter Maydell writes:

> On 12 September 2017 at 22:01, Lluís Vilanova <address@hidden> wrote:
>> This series adds an API to add instrumentation events.
>> 
>> It also provides additional APIs for:
>> * Controlling tracing events.
>> * Peek/poke guest memory.

>> Future APIs (for later series):
>> * Peek/poke guest registers.
>> * Add breakpoints to trigger instrumentation functions.
>> * Trigger instrumentation functions from guest code (former hypertrace).
>> * Add events for guest code translation/execution (once the respective 
>> tracing
>> events are accepted upstream).
>> * Add events for exceptions/syscalls.
>> * Add events for TB invalidation (necessary for libraries to deallocate any 
>> data
>> they might have allocated for the TBs they instrumented).
>> 
>> The instrumentation code is dynamically loaded as a library into QEMU either
>> when it starts or later using its remote control interfaces. The loaded code
>> only has access to function explicitly exported through the QI_VPUBLIC macro.
>> 
>> This series is branch 'devel-instrument' in
>> https://code.gso.ac.upc.edu/git/qemu-dbi.

> To parallel the comment I sent on Emilio's series: I think the
> first thing we should do here is work out the API we want to
> present to the instrumentation plugin, because that's permanent
> and we want to get it right. Then we can figure out the
> implementation details later.

> Particular notes:
>  * putting things in the instrumentation plugin API that basically
>    parallel some existing trace points is something I'm wary of,
>    because a lot of our existing tracing is "output something at
>    a point and in a way that's convenient for our internal
>    implementation", rather than "what is the right clean interface
>    to provide this sort of information". I'd rather we started
>    with a blank piece of paper and designed an API, and then
>    implemented it.

Do you have an opinion on specific trace points, or an observation in general?

I wanted to have the following events:

* cpu hotplug/hotunplug
* cpu reset
* memory access translation/execution
* BBL/TB translation/execution
* instruction translation/execution
* exceptions / syscalls


>  * I definitely don't think we should expose to the instrumentation
>    the distinction between translate time and execute time

Please see my response to your email in v6.

Also, I forgot an even simpler case, like instrumenting a subset of memory
accesses (e.g., only writes).


Thanks,
  Lluis



reply via email to

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