[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Qemu Trace
Re: [Qemu-devel] Qemu Trace
Tue, 6 Feb 2018 15:44:00 +0000
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
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.
Description: PGP signature
Re: [Qemu-devel] Qemu Trace, Nesrine Zouari, 2018/02/02