Re: [Qemu-devel] Qemu Trace

[Peter Maydell]

On 6 February 2018 at 09:17, Stefan Hajnoczi <address@hidden> wrote:
> On Mon, Feb 05, 2018 at 03:55:01PM +0000, Peter Maydell wrote:
>> ...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.

I don't really want us to end up with two separate ways of doing
basically the same thing that have been implemented entirely
independently.

A lot of the problems you need to solve (like "how do we
configurably add tracing of things like guest register changes
into the generated code in a maintainable and efficient way")
are the same both ways.

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

The plugin can register for information like changes of the
relevant system registers (and could potentially do cleverer
things like looking at guest in-memory task data structures).
QEMU doesn't need to know (and shouldn't know) that x86 CR3 or
Arm CONTEXTIDR are how you identify a guest OS task switch.

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

This only works if you have a trace event for the register change,
which we don't.

thanks
-- PMM