public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Qemu tracing
@ 2010-08-10  9:01 Prerna Saxena
  2010-08-11 16:19 ` Frank Ch. Eigler
  0 siblings, 1 reply; 2+ messages in thread
From: Prerna Saxena @ 2010-08-10  9:01 UTC (permalink / raw)
  To: systemtap
  Cc: Ananth, Stefan Hajnoczi, Mahesh Jagannath Salgaonkar, Srikar Dronamraju

Hi all,
Here's an update on a self contained userspace tracer mechanism I've
been working on, for QEMU ; alongwith Stefan Hajnoczi.
As people are aware, QEMU is a Virtual Machine Monitor/Emulator which is 
used to run fully virtualised guests using KVM or paravirtualised guests 
using Xen across a multitude of host platforms. While the cross platform 
capabilities of QEMU make it extremely popular, they put stringent 
requirements on the methods that can be employed to trace and profile a 
guest run on QEMU. QEMU runs as a userspace application on different 
hosts, and each host operating system has its own approaches to tracing 
userspace.
To make guest tracing with QEMU truly independent of the host on which
it runs, QEMU must be instrumented by self-contained tracer.
We have devised a static instrumentation framework that allows users to
record binary strings of fixed size into an internal buffer. When full,
the traces are written out to a user-specified file. The trace events
are defined in a text file, and can be toggled on/off via QEMU Monitor
commands( a console interface to QEMU )
When running QEMU on a linux host, one has the choice of using LTTnG as
the supported backend for tracing. In such case, all trace events are
compiled into equivalent LTTnG calls for logging traces. ( This was done 
with a view to ensure that a standalone userspace tracing application 
may be used as an alternative, if the qemu tracing framework is not to 
be used.)  Monitor support is currently not available for the same.

It is presently hosted at :
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/tracing ; and
would be posted upstream soon.

This is still in its nascent stages of development, with no optimization 
for calls made out for disabled trace events, etc. The performance 
penalty needs to get better as well.

It would be nice to get some feedback from tracing gurus here, on how
this can be improved.

Regards,
-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Qemu tracing
  2010-08-10  9:01 Qemu tracing Prerna Saxena
@ 2010-08-11 16:19 ` Frank Ch. Eigler
  0 siblings, 0 replies; 2+ messages in thread
From: Frank Ch. Eigler @ 2010-08-11 16:19 UTC (permalink / raw)
  To: Prerna Saxena
  Cc: systemtap, Ananth, Stefan Hajnoczi, Mahesh Jagannath Salgaonkar,
	Srikar Dronamraju


prerna wrote:

> Here's an update on a self contained userspace tracer mechanism I've
> been working on, for QEMU ; alongwith Stefan Hajnoczi.

Thank you!

> [...]
> To make guest tracing with QEMU truly independent of the host on which
> it runs, QEMU must be instrumented by self-contained tracer.

OK.
How did you choose the events (probe points) for tracing?

> When running QEMU on a linux host, one has the choice of using LTTnG
> as the supported backend for tracing.  [...]

Using <sys/sdt.h> would be a natural second alternative for linux (and
dtrace platforms, if someone cares).

Even without that, have you tried applying normal systemtap user-space
probing to qemu to get some usability / performance impressions?

- FChE

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-08-11 16:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-10  9:01 Qemu tracing Prerna Saxena
2010-08-11 16:19 ` Frank Ch. Eigler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).