public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, rkrcmar@redhat.com, mhiramat@kernel.org
Subject: Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space
Date: Fri, 2 Sep 2016 21:23:11 -0300	[thread overview]
Message-ID: <20160903002310.GB12659@amt.cnet> (raw)
In-Reply-To: <20160902101541.2b670b09@gandalf.local.home>

On Fri, Sep 02, 2016 at 10:15:41AM -0400, Steven Rostedt wrote:
> On Fri, 2 Sep 2016 09:43:01 -0400
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
> 
> > Can TSC offset changes occur at runtime?

Yes, but Linux guests don't write to the TSC offset
after booting and unless user does manual TSC writes.

> > One example is vcpu hotplug where the tracing tool would need to fetch
> > the new vcpu's TSC offset after tracing has already started.
> > 
> > Another example is if QEMU or the guest change the TSC offset while
> > running.  If the tracing tool doesn't notice this then trace events will have
> > incorrect timestamps.

So what happens is this:

HostTSC (a variable). 
GuestTSC (variable) = GuestTSCOffset (fixed) + HostTSC (variable)

Then the algorithm processes the trace as follows:
line = for each line(guest_trace)
    line = line - GuestTSCOffset (only the timestamp of course)

So from the moment the guest writes a new TSC offset, the host 
should use the new TSC offset to subtract from the trace entries.
The trace entries are in fact:

HostTSC + GuestTSCOffset

So the guest trace should contain entries for "USE NEW TSC OFFSET,
VALUE: xxx", which can be done (hum not sure if guest entries
or host entries).

However, correct me if i am wrong, the usecase seems to be:

1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

Another option is to have notifications as follows: record on a buffer 
the following:

    [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]
    [ EVENT: TSC offset write, VAL: [ host tsc value, guest tsc offset ] ]

Then when merging the trace entries, you do:

line = for each line(host trace)
    write_to_merged_trace(line)
    if (contains_tsc_offset_event(line)) {
        GuestTSCOffset = line.GuestTSCOffset
        if (!guest_tsc_offset_initialized) {
            process_all_guest_lines(
            line = line - GuestTSCOffset (only the timestamp of course)
        }
    }

Aha, fail: the traces on the host are not sufficient to know when 
to use which offset to subtract on the guest trace.

So the only possibility is to have the guest inform the occurrence
of the events: however the guest does not have access to the TSC offset.

So the host needs to inform the new tsc offset value and the guest needs
to inform when the event occurred on its side. So the algorithm can use
information on both traces to know which value to subtract on the
algorithm above.

Is this necessary? Or people do:
1) Boot guest.
2) run trace-cmd
3) run workload
4) read traces on host.

> I believe there are tracepoints for these events. They would obviously
> need to be enabled for the tracer to catch them.
> 
> I would also recommend that they go into their own instance to make
> sure other events do not overwrite them.
> 
> -- Steve

  reply	other threads:[~2016-09-03  0:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 17:05 [PATCH 0/4] kvm: export TSC offset to user-space Luiz Capitulino
2016-08-31 17:05 ` [PATCH 1/4] kvm: kvm_destroy_vm_debugfs(): check debugs_stat_data pointer Luiz Capitulino
2016-09-02 13:51   ` Paolo Bonzini
2016-08-31 17:05 ` [PATCH 2/4] kvm: kvm_create_vm_debugfs(): cleanup on error Luiz Capitulino
2016-09-02 13:53   ` Paolo Bonzini
2016-08-31 17:05 ` [PATCH 3/4] kvm: add stub for arch specific debugfs support Luiz Capitulino
2016-09-02 13:53   ` Paolo Bonzini
2016-09-03  3:34   ` Masami Hiramatsu
2016-08-31 17:05 ` [PATCH 4/4] kvm: x86: export TSC offset to user-space Luiz Capitulino
2016-09-02 13:43   ` Stefan Hajnoczi
2016-09-02 14:15     ` Steven Rostedt
2016-09-03  0:23       ` Marcelo Tosatti [this message]
2016-09-03  4:04         ` Masami Hiramatsu
2016-09-02 16:26     ` Luiz Capitulino
2016-09-02 16:29       ` Luiz Capitulino
2016-09-02 23:49     ` Marcelo Tosatti
2016-09-03  1:29       ` Luiz Capitulino
2016-09-02 17:00   ` Paolo Bonzini
2016-09-02 17:31     ` Luiz Capitulino
2016-09-05  8:10       ` Paolo Bonzini

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=20160903002310.GB12659@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=stefanha@gmail.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