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]
Message-ID: <50A355A2.5040101@hitachi.com>
Date:	Wed, 14 Nov 2012 17:26:10 +0900
From:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	David Sharp <dhsharp@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Joerg Roedel <joerg.roedel@....com>,
	Marcelo Tosatti <mtosatti@...hat.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

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(). 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ