[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu Trace

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Qemu Trace
Date: Tue, 6 Feb 2018 15:44:00 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Tue, Feb 06, 2018 at 10:55:57AM +0000, Peter Maydell wrote:
> 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.

I agree it shouldn't be duplicated.  The instrumentation plugin
infrastructure can use tracing.

What I'm not convinced of is that Nesrine's use case requires a plugin
that can react to events within QEMU.  It seems like it just needs to
export a stream of events to an external process - instrumentation
plugins aren't needed for that, just use LTTng UST.

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

Tracing already has special "tcg" events, which can be planted in
generated code as well as triggered at translation time.  So I think
this is already solved?

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

Adding a trace event for cr3 updates looks easy.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]