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

[Yoshihiro YUNOMAE]

(2013/06/11 15:50), Gleb Natapov wrote:
> 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.

OK, I'll resend a patch including vcpu_id information.

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/