Re: Re: Re: [PATCH V2 1/1] kvm/vmx: Add a tracepoint write_tsc_offset

[Gleb Natapov <gleb@redhat.com>]

On Mon, Jun 10, 2013 at 05:28:23PM -0300, Marcelo Tosatti wrote:
> On Mon, Jun 10, 2013 at 07:38:34PM +0300, Gleb Natapov wrote:
> > > Guest traces contain vcpu number and not pid (because guest is unaware
> > > of host PID).
> > > 
> > No, guest trace is just a regular ftrace done inside a guest. It contains
> > guest's PIDs which is useless for host. 
> 
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 5333/5333   #P:4
> #
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
> 
> Traces contain CPU ID.
> 
Doh, yes it does, but this is not vcpu_id. vcpu_id is seen as apic id in
a guest, so additional step is needed to map between numbers that you see
in the trace and vcpu_id. This is easy to do by looking at /proc/cpuinfo
of a guest.

> > I do not know how exactly guest traces are transfered to a host, if
> > each vcpu buffer is transfered separately host can figure out what
> > trace entry belong to which vcpu based on what buffer the trace is in.
> > But the information about what buffer belongs to which vcpu id should
> > be transfered to a host somehow too.
> > 
> > > > >                                                 However, when we
> > > > > focus on output data of the write_tsc_offset event, it is difficult to
> > > > > directly understand contents of the data if vcpu number information is
> > > > > not included. So, including the information is useful, I think.
> > > > > 
> > > > How your tool does it now?
> > > 
> > > It merges guest trace with host trace (by converting the TSC timestamp 
> > > in the guest trace to host TSC using tsc_offset information).
> > > 
> > I mean how it does it now without vcpu id. The answer is that it works
> > for only one vcpu now.
> 
> Yes.
> 
> > > By not recording vcpu ID in the tsc_offset trace, it is necessary to
> > > supply the tool with PID<->VCPU_id tuples for translation (so its an
> > > additional step required, and it makes trace merge impossible
> > > if the information is not available).
> > The tool needs PID<->VCPU_id tuples to do the merging of any trace
> > entry. Without that it does not know how to interpret entry timestamps
> > (which offset to use). Apparently it will get this information from
> > vmentry trace point. What is so special about tsc_offset tracing that
> > it needs to contain vcpuid by itself.
> 
> If the tsc_offset tracepoint contains vcpu ID, its possible to lookup
> guest trace entry (which contains CPU ID), and match on that.
> 
> Without that, PID<->VCPU_id tuples are necessary. Yes?
Ah, I think I see it now. For some reason I assumed that merge is done
for each vcpu separately, so you need to separate host events per vcpu
too, but this is not the case, host and guest event are merged based on
tsc timestamp only. In this case I see the merits of having vcpu id in
tsc_offset change trace point. It will make things easier a bit.

--
			Gleb.