Re: [Qemu-devel] [RFC] host and guest kernel trace merging

[Stefan Hajnoczi]

On Thu, Mar 03, 2016 at 02:35:01PM -0500, Luiz Capitulino wrote:
> trace-cmd-server
> ================
> 
> Everything I described could look like this:
> 
>   # trace-cmd server [ in the host ]
>   # trace-cmd record [ in the guest ]
>   # trace-cmd report [ in the host, to merge the traces ]
> 
> To achieve this, we need two things:
> 
>  1. Add an interface to obtain the guest TSC offset from the
>     host user-space.
> 
>     Maybe we could have a new sysfs directory, with a file
>     per vCPU thread and the offset as contents? Or maybe
>     just add a new entry to /proc/, like: /proc/TID/tsc-offset?

Yes, the interface is missing.  In the past I have heard people using
trace events on the host to:

1. Collect tsc offsets
2. Track which vCPU is scheduled to a host CPU

So instead of relying on an interface they enable the relevant trace
events on the host and then parse the trace to collect this information.
However, it's a bad solution especially for tsc offsets since you may
wish to trace an already-running VM where the tracepoint that records
the tsc offset may not fire after startup (?).

Therefore, I agree that an interface for the tsc offset is needed.

>  2. Build a trace-cmd-server
> 
>     Which does the following:
> 
>       1. Receive trace-cmd record commands from a guest,
>          to be performed in the host

Sometimes the opposite is desirable: the host controls tracing inside
the guest.  Any thoughts on this use case?

>       2. Read the TSC offset for vCPUs being traced
> 
>       3. Read the CPU frequency for --ts2secs
> 
>       4. Receive the guest.dat from the guest and store it together
>          with the host's
> 
>     I'd suggest the default communication between guest and
>     host be via networking. Then we add vsock support when it's
>     available.

signature.asc
Description: PGP signature