Re: [Qemu-devel] [PATCH v2 4/4] trace: add ability to do simple printf logging via systemtap

[Daniel P . Berrangé]

On Fri, Jan 18, 2019 at 12:14:14PM -0600, Eric Blake wrote:
> On 1/18/19 11:31 AM, Daniel P. Berrangé wrote:
> > The dtrace systemtap trace backend for QEMU is very powerful but it is
> > also somewhat unfriendly to users who aren't familiar with systemtap,
> > or who don't need its power right now.
> > 
> >   stap -e "....some strange script...."
> > 
> 
> > We go one step further though and introduce a 'qemu-trace-stap' tool to
> > make this even easier
> > 
> >  $ qemu-trace-stap run qemu-system-x86_64 qio*
> >  address@hidden qio_channel_socket_new Socket new ioc=0x56135d1d7c00
> 
> One thing I did not immediately get on the first read, and therefore
> which may be worth mentioning in the docs portion of the patch:
> 
> Am I correct that stap is always run as a separate process from the
> process(es) being traced, and that you can start the two in either order
> (qemu first, then stap; or stap first, then qemu), where the tracing is
> effectively output as long as both processes are running and trace
> points being hit in the qemu process?

If you're using the stap binary directly you have a choice of it
working against any existing process on the system, or you can have
it launch the process on your behalf and target just that one process.

For our wrapper script I'm only targetting the former, since I think
the common case is that someone/something else has already run the
QEMU process. I could however easily add a "-p PID" option too which
would allow the trace to be tailored to a specific QEMU process, instead
of all running QEMU processes.

And yes, there's no ordering dependancy - unless it is critical that
you see traces from QEMU's early initialization of course, in which
case you'd launch the tracing first.

> >  5 files changed, 339 insertions(+), 1 deletion(-)
> >  create mode 100755 scripts/qemu-trace-stap
> >  create mode 100644 scripts/tracetool/format/log_stap.py
> > 
> > diff --git a/Makefile b/Makefile
> > index dccba1dca2..22e481e7ba 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -736,6 +736,9 @@ endif
> >  ifneq ($(HELPERS-y),)
> >     $(call install-prog,$(HELPERS-y),$(DESTDIR)$(libexecdir))
> >  endif
> > +ifdef CONFIG_TRACE_SYSTEMTAP
> > +   $(INSTALL_PROG) "scripts/qemu-trace-stap" $(DESTDIR)$(bindir)
> > +endif
> 
> No man page being installed?  If we're planning on this binary being
> available on a similar par with qemu-io, it deserves some installed
> documentation.

Heh, no good deed / quick enhancement goes unpunished :-P Yes, I'll
do a proper job of this and write a man page too :-)


> > +To watch all trace points on the qemu-system-x86_64 binary:
> > +
> > +   %(argv0)s run qemu-system-x86_64
> > +
> > +To only watch the trace points matching the qio* and qcrypto* patterns
> > +
> > +   %(argv0)s run qemu-system-x86_64 qio* qcrypto*
> 
> This output is not copy-pastable - it includes shell globs which might
> inadvertantly expand based on the contents of $PWD. Should you amend the
> output to be properly quoted for reuse in shell commands?

Yes, that is true


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|