From: "Lluís Vilanova" <vilanova@ac.upc.edu>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
"Emilio G. Cota" <cota@braap.org>,
Markus Armbruster <armbru@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation
Date: Fri, 15 Sep 2017 16:45:42 +0300 [thread overview]
Message-ID: <877ex0gjnd.fsf@frigg.lan> (raw)
In-Reply-To: <CAFEAcA-rmX=gUdYTLK4g5TAWVTkCfkbkXXfCxmaaivv8XGdMXg@mail.gmail.com> (Peter Maydell's message of "Thu, 14 Sep 2017 15:54:28 +0100")
Peter Maydell writes:
> On 12 September 2017 at 22:01, Lluís Vilanova <vilanova@ac.upc.edu> 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
next prev parent reply other threads:[~2017-09-15 13:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 21:01 [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation Lluís Vilanova
2017-09-12 21:05 ` [Qemu-devel] [PATCH v5 01/22] instrument: Add documentation Lluís Vilanova
2017-09-12 21:09 ` [Qemu-devel] [PATCH v5 02/22] instrument: Add configure-time flag Lluís Vilanova
2017-09-12 21:13 ` [Qemu-devel] [PATCH v5 03/22] instrument: Add generic library loader Lluís Vilanova
2017-09-12 21:17 ` [Qemu-devel] [PATCH v5 04/22] instrument: [linux-user] Add command line " Lluís Vilanova
2017-09-12 21:21 ` [Qemu-devel] [PATCH v5 05/22] instrument: [bsd-user] " Lluís Vilanova
2017-09-12 21:25 ` [Qemu-devel] [PATCH v5 06/22] instrument: [softmmu] " Lluís Vilanova
2017-09-12 21:29 ` [Qemu-devel] [PATCH v5 07/22] instrument: [qapi] Add " Lluís Vilanova
2017-09-12 21:34 ` [Qemu-devel] [PATCH v5 08/22] instrument: [hmp] " Lluís Vilanova
2017-09-12 21:38 ` [Qemu-devel] [PATCH v5 09/22] instrument: Add basic control interface Lluís Vilanova
2017-09-12 21:42 ` [Qemu-devel] [PATCH v5 10/22] instrument: Add support for tracing events Lluís Vilanova
2017-09-12 21:46 ` [Qemu-devel] [PATCH v5 11/22] instrument: Track vCPUs Lluís Vilanova
2017-09-12 21:50 ` [Qemu-devel] [PATCH v5 12/22] instrument: Add event 'guest_cpu_enter' Lluís Vilanova
2017-09-12 21:54 ` [Qemu-devel] [PATCH v5 13/22] instrument: Support synchronous modification of vCPU state Lluís Vilanova
2017-09-12 21:58 ` [Qemu-devel] [PATCH v5 14/22] exec: Add function to synchronously flush TB on a stopped vCPU Lluís Vilanova
2017-09-12 22:02 ` [Qemu-devel] [PATCH v5 15/22] instrument: Add event 'guest_cpu_exit' Lluís Vilanova
2017-09-12 22:06 ` [Qemu-devel] [PATCH v5 16/22] instrument: Add event 'guest_cpu_reset' Lluís Vilanova
2017-09-12 22:10 ` [Qemu-devel] [PATCH v5 17/22] trace: Introduce a proper structure to describe memory accesses Lluís Vilanova
2017-09-12 22:14 ` [Qemu-devel] [PATCH v5 18/22] instrument: Add event 'guest_mem_before_trans' Lluís Vilanova
2017-09-12 22:18 ` [Qemu-devel] [PATCH v5 19/22] instrument: Add event 'guest_mem_before_exec' Lluís Vilanova
2017-09-12 22:22 ` [Qemu-devel] [PATCH v5 20/22] instrument: Add event 'guest_user_syscall' Lluís Vilanova
2017-09-12 22:26 ` [Qemu-devel] [PATCH v5 21/22] instrument: Add event 'guest_user_syscall_ret' Lluís Vilanova
2017-09-12 22:30 ` [Qemu-devel] [PATCH v5 22/22] instrument: Add API to manipulate guest memory Lluís Vilanova
2017-09-12 22:34 ` [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation no-reply
2017-09-13 9:45 ` Lluís Vilanova
2017-09-12 22:36 ` no-reply
2017-09-13 9:50 ` Lluís Vilanova
2017-09-14 14:54 ` Peter Maydell
2017-09-15 13:45 ` Lluís Vilanova [this message]
2017-09-15 13:49 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ex0gjnd.fsf@frigg.lan \
--to=vilanova@ac.upc.edu \
--cc=armbru@redhat.com \
--cc=cota@braap.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.