linux-kernel - Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 16 Nov 2012 17:15:37 -0200
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	David Sharp <dhsharp@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, Joerg Roedel <joerg.roedel@....com>,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Ingo Molnar <mingo@...hat.com>, Avi Kivity <avi@...hat.com>,
	yrl.pp-manager.tt@...achi.com,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset

On Wed, Nov 14, 2012 at 05:26:10PM +0900, Yoshihiro YUNOMAE wrote:
> Thank you for commenting on my patch set.
> 
> (2012/11/14 11:31), Steven Rostedt wrote:
> >On Tue, 2012-11-13 at 18:03 -0800, David Sharp wrote:
> >>On Tue, Nov 13, 2012 at 6:00 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >>>On Wed, 2012-11-14 at 10:36 +0900, Yoshihiro YUNOMAE wrote:
> >>>
> >>>>To merge the data like previous pattern, we apply this patch set. Then, we can
> >>>>get TSC offset of the guest as follows:
> >>>>
> >>>>$ dmesg | grep kvm
> >>>>[   57.717180] kvm: (2687) write TSC offset 18446743360465545001, now clock ##
> >>>>                      ^^^^                   ^^^^^^^^^^^^^^^^^^^^            |
> >>>>                      PID                         TSC offset                 |
> >>>>                                                            HOST TSC value --+
> >>>>
> >>>
> >>>Using printk to export something like this is IMO a nasty hack.
> >>>
> >>>Can't we create a /sys or /proc file to export the same thing?
> >>
> >>Since the value changes over the course of the trace, and seems to be
> >>part of the context of the trace, I think I'd include it as a
> >>tracepoint.
> >>
> >
> >I'm fine with that too.
> 
> Using some tracepoint is a nice idea, but there is one problem. Here,
> our discussion point is "the event which TSC offset is changed does not
> frequently occur, but the buffer must keep the event data."
> 
> There are two ideas for using tracepoint. First, we define new
> tracepoint for changed TSC offset. This is simple and the overhead will
> be low. However, this trace event stored in the buffer will be
> overwritten by other trace events because this TSC offset event does
> not frequently occur. Second, we add TSC offset information to the
> tracepoint frequently occured. For example, we assume that TSC offset
> information is added to arguments of trace_kvm_exit().

The TSC offset is in the host trace. So given a host trace with two TSC
offset updates, how do you know which events in the guest trace
(containing a number of events) refer to which tsc offset update?

Unless i am missing something, you can't solve this easily (well, except
exporting information to the guest that allows it to transform RDTSC ->
host TSC value, which can be done via pvclock).

Another issue as mentioned is lack of TSC synchronization in the host.
Should you provide such a feature without the possibility of proper
chronological order on systems with unsynchronized TSC?

> By adding the
> information to the arguments, we can avoid the situation where the TSC
> offset information is overwritten by other events. However, TSC offset
> is not frequently changed and same information is output many times
> because almost all data are waste. Therefore, only using tracepoint
> is not good idea.
> 
> So, I suggest a hybrid method; record TSC offset change events and read
> the last TSC offset from procfs when collecting the trace data.
> In particular, the method is as follows:
>  1. Enable the tracepoint of TSC offset change and record the value
>     before and after changing
>  2. Start tracing
>  3. Stop tracing
>  4. Collect trace data and read /proc/pid/kvm/*
>  5. Check if any trace event recording the two TSC offsets exists
>     in the trace data
>     if(existing) => use trace event (flow 6)
>     else         => use /proc/pid/kvm/* (flow 7)
>  6. Apply two TSC offsets of the trace event to the trace data and
>     sort the trace data
> 　　(Ex.)
>         * => tracepoint of changing TSC offset
>         . => another trace event
> 
> 　　[START]............*............[END]
>          <----------> <---------->
>            previous      current
>           TSC offset   TSC offset
> 
>  7. Apply TSC offset of /proc/pid/kvm/* to the trace data and
>     sort the trace data
>    (Ex.)
>         . => another trace event(not tracepoint of changing TSC offset)
> 
> 　　[START].........................[END]
>          <----------------------->
>                  current
>                TSC offset
> 
> Thanks,
> 
> -- 
> Yoshihiro YUNOMAE
> Software Platform Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: yoshihiro.yunomae.ez@...achi.com
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/