From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
David Sharp <dhsharp@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>,
Ingo Molnar <mingo@redhat.com>,
yrl.pp-manager.tt@hitachi.com,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Re: Re: [PATCH V2 1/1] kvm/vmx: Add a tracepoint write_tsc_offset
Date: Mon, 10 Jun 2013 17:28:23 -0300 [thread overview]
Message-ID: <20130610202823.GC31409@amt.cnet> (raw)
In-Reply-To: <20130610163834.GG29022@redhat.com>
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.
> 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?
next prev parent reply other threads:[~2013-06-10 20:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-04 8:36 [PATCH V2 0/1] kvm/vmx: Output TSC offset Yoshihiro YUNOMAE
2013-06-04 8:36 ` [PATCH V2 1/1] kvm/vmx: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE
2013-06-06 0:23 ` Marcelo Tosatti
2013-06-06 11:33 ` Gleb Natapov
2013-06-06 21:43 ` Marcelo Tosatti
2013-06-07 5:22 ` Yoshihiro YUNOMAE
2013-06-07 21:55 ` Marcelo Tosatti
2013-06-09 11:14 ` Gleb Natapov
2013-06-10 9:30 ` Yoshihiro YUNOMAE
2013-06-10 10:05 ` Gleb Natapov
2013-06-10 11:37 ` Yoshihiro YUNOMAE
2013-06-10 14:04 ` Marcelo Tosatti
2013-06-10 16:38 ` Gleb Natapov
2013-06-10 20:28 ` Marcelo Tosatti [this message]
2013-06-11 6:50 ` Gleb Natapov
2013-06-11 9:26 ` Yoshihiro YUNOMAE
2013-06-04 8:38 ` [EXAMPLE] tools: a tool for merging trace data of a guest and a host Yoshihiro YUNOMAE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130610202823.GC31409@amt.cnet \
--to=mtosatti@redhat.com \
--cc=dhsharp@google.com \
--cc=gleb@redhat.com \
--cc=hidehiro.kawai.ez@hitachi.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=yoshihiro.yunomae.ez@hitachi.com \
--cc=yrl.pp-manager.tt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox