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.
Attachment:
signature.asc
Description: PGP signature
