Linux-Trace-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Dario Faggioli <dfaggioli@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Stefano De Venuto <stefano.devenuto99@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [RFC] Simple tool for VMEnters/VMExits matching and trace validation
Date: Sat, 17 Apr 2021 08:43:07 +0200
Message-ID: <8cd07e86b6e728bc7b74b39d52833715cecdc24c.camel@suse.com> (raw)
In-Reply-To: <20210416173235.11b0d1c0@gandalf.local.home>


[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]

On Fri, 2021-04-16 at 17:32 -0400, Steven Rostedt wrote:
> On Fri, 16 Apr 2021 22:48:38 +0200
> Stefano De Venuto <stefano.devenuto99@gmail.com> wrote:
> > 
> > Yes. An example of those events is visible in this trace:
> > 
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175367012:
> > kvm_entry:            vcpu 0, rip 0xffffffff84a792b6
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175253942:
> > write_msr:            c0011020, value 0
> > trace-tumbleweed.dat:           <idle>-0     [000]14320175283462:
> > hrtimer_cancel:       hrtimer=0xffff9002fdc21a00
> > trace-tumbleweed.dat:           <idle>-0     [000]14320175291336:
> > hrtimer_expire_entry: hrtimer=0xffff9002fdc21a00
> > function=tick_sched_timer now=3601121397289
> > trace-tumbleweed.dat:           <idle>-0     [000]14320175317345:
> > hrtimer_expire_exit:  hrtimer=0xffff9002fdc21a00
> > trace-tumbleweed.dat:           <idle>-0     [000]14320175319329:
> > hrtimer_start:        hrtimer=0xffff9002fdc21a00
> > function=tick_sched_timer expires=3601125253926
> > softexpires=3601125253926 mode=0x0
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175331517:
> > write_msr:            c0011020, value 40000000000000
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175338548:
> > kvm_wait_lapic_expire: vcpu 0: delta 534432 (late)
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175341750:
> > kvm_eoi:              apicid 0 vector 236
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175343465:
> > kvm_pv_eoi:           apicid 0 vector 236
> >            trace.dat:        CPU 0/KVM-1567  [001]14320175345704:
> > kvm_exit:             vcpu 0 reason msr rip 0xffffffff84a792b4
> > info1 0x0000000000000001 info2 0x0000000000000000 intr_info
> > 0x00000000 error_code 0x00000000
> 
> Is the above with the time negotiations working fine?
> 
Yes. I think this is still with PTP.

But this time, this is actually all about the host.

> We do not yet support the guest shift, as we found that it was broken
> (I
> believe you reported that) and we do not have a machine available to
> that
> has that feature :-/
> 
Sure, but the problem here is that write_msr, kvm_wait_lapic_expire,
kvm_eoi, kvm_pv_eoi in trace.dat (which is the host trace), despite
happening after the VMExit, are shown before kvm_exit.

This, we think, has to do to where the call to trace_kvm_exit() is in
the kernel, and that's why we said we'll send a patch to move it.

It was just an example of what and how one can use the simple little
tool that Stefano has made on top of libkshark, as it was what helped
us spot this problem. :-)

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 16:46 Stefano De Venuto
2021-04-16 17:47 ` Dario Faggioli
2021-04-16 20:48   ` Stefano De Venuto
2021-04-16 21:32     ` Steven Rostedt
2021-04-17  6:43       ` Dario Faggioli [this message]
2021-04-20  8:12 ` Yordan Karadzhov
2021-04-21  2:17   ` Steven Rostedt
2021-04-21  9:14     ` Yordan Karadzhov
2021-05-01  6:11     ` Stefano De Venuto
2021-05-01  6:11   ` Stefano De Venuto

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=8cd07e86b6e728bc7b74b39d52833715cecdc24c.camel@suse.com \
    --to=dfaggioli@suse.com \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stefano.devenuto99@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

Linux-Trace-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-trace-devel/0 linux-trace-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-trace-devel linux-trace-devel/ https://lore.kernel.org/linux-trace-devel \
		linux-trace-devel@vger.kernel.org
	public-inbox-index linux-trace-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-trace-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git