Re: [Qemu-devel] [RFC] tracing: per-CPU tracing state

[Stefan Hajnoczi]

On Tue, Nov 9, 2010 at 3:11 PM, Lluís <address@hidden> wrote:
> Stefan Hajnoczi writes:
>
>> On Mon, Nov 8, 2010 at 2:35 PM, Lluís <address@hidden> wrote:
>>> Another important change would be to provide a generic interface inside
>>> QEMU that provides a programmatic control of the tracing state of all
>>> events (both per-cpu and global), and let each backend provide a small
>>> .c file implementing that functionality. This would provide a
>>> centralized point through QEMU monitor for the control of tracing
>>> events, plus any backend-specific control interface that might also be
>>> available.
>
>> Programmatic control can't be provided for all backends.
>
>> If you're using a platform-specific trace backend then you probably
>> want to use those tools.  For example, DTrace has a powerful language
>> for aggregating trace data and reporting.  DTrace isn't about
>> enabling/disabling probes, it does much more which we cannot usefully
>> work into a common subset interface.  UST has its own control tool to
>> query and configure tracepoints in a running process.
>
>> I think it makes sense to use each backend's native tools.  If we try
>> to come up with a common interface it will cost effort to maintain and
>> users will be better off using the native tools.  Imagine a Fedora
>> user wanting to instrument QEMU, why learn a QEMU-specific subset
>> interface rather than using SystemTap in the same way you can
>> instrument the kernel or other applications?
>
>> The simple backend is built in to QEMU and therefore does need a
>> HMP/QMP interface for control.
>
>> Am I missing the cases where a common interface is useful?
>
> I see. My current concern is how to integrate the per-vCPU state with
> the backend-specific per-event state.
>
> Right now I have a programmatic interface for controlling the per-vCPU
> state, but that is oblivious of the global backend-specific per-event
> state (which must be enabled beforehand), but I dont know how to provide
> per-backend _and_ per-vCPU control of tracing state.
>
> Maybe it's just not necessary, given that the trace events I'm inserting
> are disabled by default, and then it's just a matter of flipping two
> bits instead of one (although from separate tools).

Yes, it's not ideal but sounds like the simplest option to start with.

Some trace mechanisms support filter expressions to record only a
subset of the trace events.  For example, sun4m_cpu_reset_interrupt
when cpu==1 && level>2.  I think trace events in the Linux kernel have
a certain amount of context information like the physical cpu number
and you can filter on it.  The per-vcpu filtering could be solved with
filtering but neither the simple trace backend nor external trace
backends support vcpu as a first-class concept.

Stefan