Re: [Qemu-devel] Qemu Trace

[Stefan Hajnoczi]

On Mon, Feb 05, 2018 at 03:55:01PM +0000, Peter Maydell wrote:
> 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.

There are two cases for online processing:

1. Synchronous - this is what the instrumentation plugins will be able
   to do.  It means that QEMU waits until the event has been processed,
   and the plugin is therefore able to control QEMU.

2. Asynchronous - this is what LTTng UST does.  It means that the
   process analyzing the trace does not hold up QEMU, but it cannot
   control QEMU without some delay between trace events firing and
   reacting to them.  I think Nesrine's use case is this one.

#2 is useful for "real-time" graphs, for example.  That is still
"oneline" but it doesn't require instrumentation plugins.

Given that the instrumentation plugin API is still in early development,
it would delay Nesrine's work and I recommend against depending on it.

> 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.

How do you envision that instrumentation plugins will monitor guest OS
task switches if QEMU does not know about them?

Without instrumentation plugins I would add a guest_x86_cr3_write trace
event, for example.  Then the trace consumer can interpret that event as
a task switch if it knows the guest OS always writes to the cr3 register
on a task switch.  No instrumentation plugins are necessary in order to
do this and it doesn't hardcode knowledge of guest OS task switching
into QEMU either.

Stefan

signature.asc
Description: PGP signature