Re: [Qemu-devel] Qemu Trace

[Peter Maydell]

On 5 February 2018 at 15:51, Stefan Hajnoczi <address@hidden> wrote:
> The point of the instrumentation plugin API is for online analysis
> (stuff that cannot be post-processed offline) with the ability for the
> plugin to control QEMU (e.g. affect translation during a run).  That is
> not necessary for Nesrine's use case.

...but it hugely overlaps, because the most interesting
reason for having a trace plugin is to be able to do things
like tracing instruction flow, memory access and so on.

> I see two main requirements in Nesrine's use case:
>
> 1. Instruction flow, memory access, and task switch trace.  This doesn't
> exist today and requires adding new trace events.
>
> 2. An external interface for processing traces.  There seems to be a
> requirement for doing it online and not by post-processing trace files.
> Therefore I suggested looking into LTTng UST, which has an efficient
> interface and libraries for tracing processes.  I think no QEMU changes
> are necessary here.

...and "online processing of traces" is pretty much exactly
what an instrumentation plugin API is for.

It would also let you put the logic of "how do we know what a
guest OS task switch is anyway" somewhere other than QEMU,
which is nice because that's very guest-OS specific.

thanks
-- PMM