On Thu, Mar 24, 2016 at 04:42:42PM +0800, Peter Xu wrote: > On Fri, Mar 04, 2016 at 11:19:33AM +0000, Stefan Hajnoczi wrote: > > 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. > > It seems that KVM still has no such a generic interface to query VM > status, right? How about we create one for it? As a start, we can > make it fairly simple. Afterward, we can enrich it when > necessary. For example: > > we create this directory to store all KVM guest informations (or > general KVM dynamic informations): > > /sys/hypervisor/kvm/ > > For each VM, we can have this to store VM specific infos: > > /sys/hypervisor/kvm/$VM_NAME > > For each vCPU: > > /sys/hypervisor/kvm/$VM_NAME/cpus/cpuN/ > > and we can put tsc-offset here like: > > /sys/hypervisor/kvm/$VM_NAME/cpus/cpuN/tsc-offset > > Would this be workable? There are probably race conditions if the tsc offset is queried independently from the trace collection. For example, imagine the host is suspend right when tracing begins. I think the TSC could be adjusted when the host wakes up again. Ideally the TSC information would be part of the trace data so that there are no race conditions when interpeting time stamps. Maybe TSC changes are so infrequent that this doesn't matter... Perhaps folks who understand TSC better have an opinion on this. Stefan
Attachment:
signature.asc
Description: PGP signature
