[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Xu
Subject: Re: [Qemu-devel] [RFC] host and guest kernel trace merging
Date: Thu, 24 Mar 2016 16:42:42 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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):


For each VM, we can have this to store VM specific infos:


For each vCPU:


and we can put tsc-offset here like:


Would this be workable?


-- peterx

reply via email to

[Prev in Thread] Current Thread [Next in Thread]