On Tue, Feb 06, 2018 at 10:55:57AM +0000, Peter Maydell wrote: > On 6 February 2018 at 09:17, Stefan Hajnoczi <stefa...@redhat.com> 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. Stefan
signature.asc
Description: PGP signature
