[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
- [Qemu-devel] [PATCH v5 18/22] instrument: Add event 'guest_mem_before_trans', (continued)
- [Qemu-devel] [PATCH v5 18/22] instrument: Add event 'guest_mem_before_trans', Lluís Vilanova, 2017/09/12
- [Qemu-devel] [PATCH v5 19/22] instrument: Add event 'guest_mem_before_exec', Lluís Vilanova, 2017/09/12
- [Qemu-devel] [PATCH v5 20/22] instrument: Add event 'guest_user_syscall', Lluís Vilanova, 2017/09/12
- [Qemu-devel] [PATCH v5 21/22] instrument: Add event 'guest_user_syscall_ret', Lluís Vilanova, 2017/09/12
- [Qemu-devel] [PATCH v5 22/22] instrument: Add API to manipulate guest memory, Lluís Vilanova, 2017/09/12
- Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation, no-reply, 2017/09/12
- Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation, no-reply, 2017/09/12
- Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation, Peter Maydell, 2017/09/14
- Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation,
Lluís Vilanova <=