[PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Tzvetomir Stoyanov (VMware)]

From: "Tzvetomir (VMware)  Stoyanov" <tz.stoyanov@gmail.com>

The tracefs library provides APIs for accessing files from tracefs.
The library is part of trace-cmd, it is installed as part of trace-cmd
installation. KernelShark uses some of those APIs and must be linked with
the library

Tzvetomir (VMware)  Stoyanov (2):
  KernelShark2.0: Link KernelShark to libtracefs
  KernelShark2.0: Use libtracefs APIs to access tracefs

 CMakeLists.txt           |  3 ++-
 build/FindTraceCmd.cmake | 28 ++++++++++++++++++++++++++++
 src/CMakeLists.txt       |  2 ++
 src/libkshark-tepdata.c  |  5 +++--
 4 files changed, 35 insertions(+), 3 deletions(-)

-- 
2.24.1

[PATCH 1/2] KernelShark2.0: Link KernelShark to libtracefs

[Tzvetomir Stoyanov (VMware)]

From: Tzvetomir (VMware)  Stoyanov <tz.stoyanov@gmail.com>

The tracefs library provides APIs for accessing files from tracefs.
The library is part of trace-cmd, it is installed as part of trace-cmd
installation. KernelShark uses some of those APIs and must be linked with
the library

Signed-off-by: Tzvetomir (VMware)  Stoyanov <tz.stoyanov@gmail.com>
---
 CMakeLists.txt           |  3 ++-
 build/FindTraceCmd.cmake | 28 ++++++++++++++++++++++++++++
 src/CMakeLists.txt       |  2 ++
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ce2a5ef..846fcf2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -79,7 +79,8 @@ include_directories(${KS_DIR}/src/
                     ${KS_DIR}/build/src/
                     ${JSONC_INCLUDE_DIR}
                     ${TRACECMD_INCLUDE_DIR}
-                    ${TRACEEVENT_INCLUDE_DIR})
+                    ${TRACEEVENT_INCLUDE_DIR}
+                    ${TRACEFS_INCLUDE_DIR})
 
 message("")
 message(STATUS "C flags      : " ${CMAKE_C_FLAGS})
diff --git a/build/FindTraceCmd.cmake b/build/FindTraceCmd.cmake
index 6278190..802d42e 100644
--- a/build/FindTraceCmd.cmake
+++ b/build/FindTraceCmd.cmake
@@ -6,6 +6,8 @@
 #  TRACEEVENT_FOUND, If false, do not try to use traceevent.
 #
 #  TRACECMD_INCLUDE_DIR, where to find trace-cmd header.
+#  TRACEFS_INCLUDE_DIR, where to find tracefs header.
+#  TRACEFS_LIBRARY, the tracefs library.
 #  TRACECMD_LIBRARY, the trace-cmd library.
 #  TRACECMD_FOUND, If false, do not try to use trace-cmd.
 
@@ -31,10 +33,18 @@ find_path(TRACECMD_INCLUDE_DIR   NAMES  trace-cmd/trace-cmd.h
                                  PATHS  $ENV{TRACE_CMD}/include/
                                  NO_DEFAULT_PATH)
 
+find_path(TRACEFS_INCLUDE_DIR    NAMES  tracefs/tracefs.h
+                                 PATHS  $ENV{TRACE_CMD}/include/
+                                NO_DEFAULT_PATH)
+
 find_library(TRACECMD_LIBRARY    NAMES  trace-cmd/libtracecmd.so
                                  PATHS  $ENV{TRACE_CMD}/lib/
                                  NO_DEFAULT_PATH)
 
+find_library(TRACEFS_LIBRARY    NAMES  tracefs/libtracefs.so
+                                PATHS  $ENV{TRACE_CMD}/lib/
+                                NO_DEFAULT_PATH)
+
 find_path(TRACEEVENT_INCLUDE_DIR NAMES  traceevent/event-parse.h
                                  PATHS  $ENV{TRACE_CMD}/include/
                                  NO_DEFAULT_PATH)
@@ -47,7 +57,9 @@ find_library(TRACEEVENT_LIBRARY  NAMES  traceevent/libtraceevent.so
 # search was successful "find_path" will do nothing this time.
 find_program(TRACECMD_EXECUTABLE NAMES  trace-cmd)
 find_path(TRACECMD_INCLUDE_DIR   NAMES  trace-cmd/trace-cmd.h)
+find_path(TRACEFS_INCLUDE_DIR   NAMES  tracefs/tracefs.h)
 find_library(TRACECMD_LIBRARY    NAMES  trace-cmd/libtracecmd.so)
+find_library(TRACEFS_LIBRARY    NAMES  tracefs/libtracefs.so)
 find_path(TRACEEVENT_INCLUDE_DIR NAMES  traceevent/event-parse.h)
 find_library(TRACEEVENT_LIBRARY  NAMES  traceevent/libtraceevent.so)
 
@@ -67,6 +79,22 @@ ELSE (TRACECMD_FOUND)
 
 ENDIF (TRACECMD_FOUND)
 
+IF (TRACEFS_INCLUDE_DIR AND TRACEFS_LIBRARY)
+
+  SET(TRACEFS_FOUND TRUE)
+
+ENDIF (TRACEFS_INCLUDE_DIR AND TRACEFS_LIBRARY)
+
+IF (TRACEFS_FOUND)
+
+  MESSAGE(STATUS "Found tracefs: ${TRACEFS_LIBRARY}")
+
+ELSE (TRACEFS_FOUND)
+
+  MESSAGE(FATAL_ERROR "\nCould not find tracefs!\n")
+
+ENDIF (TRACEFS_FOUND)
+
 
 IF (TRACEEVENT_INCLUDE_DIR AND TRACEEVENT_LIBRARY)
 
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index dbd33ab..8ffc66c 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -19,6 +19,7 @@ add_library(kshark SHARED libkshark.c
 
 target_link_libraries(kshark ${TRACEEVENT_LIBRARY}
                              ${TRACECMD_LIBRARY}
+                             ${TRACEFS_LIBRARY}
                              ${JSONC_LIBRARY}
                              ${CMAKE_DL_LIBS})
 
@@ -104,6 +105,7 @@ if (Qt5Widgets_FOUND AND Qt5Network_FOUND)
                                      Qt5::Network
                                      ${TRACEEVENT_LIBRARY}
                                      ${TRACECMD_LIBRARY}
+                                     ${TRACEFS_LIBRARY}
                                      ${CMAKE_DL_LIBS})
 
     set_target_properties(kshark-gui PROPERTIES  SUFFIX ".so.${KS_VERSION_STRING}")
-- 
2.24.1

[PATCH 2/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Tzvetomir Stoyanov (VMware)]

From: Tzvetomir (VMware)  Stoyanov <tz.stoyanov@gmail.com>

KernelShark uses trace-cmd APIs to access tracefs. Now those
APIs are moved to libtracefs:
 tracecmd_get_tracing_dir() -> tracefs_get_tracing_dir()
 tracecmd_local_events() -> tracefs_local_events()
 tracecmd_local_plugins() -> tracefs_tracers()

Signed-off-by: Tzvetomir (VMware)  Stoyanov <tz.stoyanov@gmail.com>
---
 src/libkshark-tepdata.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/libkshark-tepdata.c b/src/libkshark-tepdata.c
index ed61f76..8678e12 100644
--- a/src/libkshark-tepdata.c
+++ b/src/libkshark-tepdata.c
@@ -19,6 +19,7 @@
 
 // trace-cmd
 #include "trace-cmd/trace-cmd.h"
+#include "tracefs/tracefs.h"
 
 // KernelShark
 #include "libkshark-plugin.h"
@@ -1066,7 +1067,7 @@ int kshark_tep_init_local(struct kshark_data_stream *stream)
 	if (!tep_handle)
 		return -EFAULT;
 
-	tep_handle->tep = tracecmd_local_events(tracecmd_get_tracing_dir());
+	tep_handle->tep = tracefs_local_events(tracefs_get_tracing_dir());
 	if (!tep_handle->tep)
 		goto fail;
 
@@ -1233,5 +1234,5 @@ int kshark_tep_get_event_fields(struct kshark_data_stream *stream,
 /** Get an array of available tracer plugins. */
 char **kshark_tracecmd_local_plugins()
 {
-	return tracecmd_local_plugins(tracecmd_get_tracing_dir());
+	return tracefs_tracers(tracefs_get_tracing_dir());
 }
-- 
2.24.1

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Steven Rostedt]

On Fri,  6 Mar 2020 11:29:00 +0200
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:

> From: "Tzvetomir (VMware)  Stoyanov" <tz.stoyanov@gmail.com>
> 
> The tracefs library provides APIs for accessing files from tracefs.
> The library is part of trace-cmd, it is installed as part of trace-cmd
> installation. KernelShark uses some of those APIs and must be linked with
> the library
> 
> Tzvetomir (VMware)  Stoyanov (2):
>   KernelShark2.0: Link KernelShark to libtracefs
>   KernelShark2.0: Use libtracefs APIs to access tracefs
> 

I added these patches to the latest kernelshark-2.0 and it still doesn't
work for me. I did a little debugging, and noticed that it fails while
reading the guest trace.dat file with:

plugin "kvm_combo" failed to initialize on stream /tmp/trace-host-Fedora21.

It seems to require that the guest trace.dat file has kvm events?

Note, as I build my guest kernel with a make localmodconfig, which disables
all modules that are not necessary to boot the box, there is no kvm events
there. I can see why the host may need them, but not the guest. I'll
rebuild my guest kernel with kvm events and see if that solves this (but
that shouldn't be the case).

-- Steve

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Steven Rostedt]

On Fri, 6 Mar 2020 15:13:56 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri,  6 Mar 2020 11:29:00 +0200
> "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:
> 
> > From: "Tzvetomir (VMware)  Stoyanov" <tz.stoyanov@gmail.com>
> > 
> > The tracefs library provides APIs for accessing files from tracefs.
> > The library is part of trace-cmd, it is installed as part of trace-cmd
> > installation. KernelShark uses some of those APIs and must be linked with
> > the library
> > 
> > Tzvetomir (VMware)  Stoyanov (2):
> >   KernelShark2.0: Link KernelShark to libtracefs
> >   KernelShark2.0: Use libtracefs APIs to access tracefs
> >   
> 
> I added these patches to the latest kernelshark-2.0 and it still doesn't
> work for me. I did a little debugging, and noticed that it fails while
> reading the guest trace.dat file with:
> 
> plugin "kvm_combo" failed to initialize on stream /tmp/trace-host-Fedora21.
> 
> It seems to require that the guest trace.dat file has kvm events?
> 
> Note, as I build my guest kernel with a make localmodconfig, which disables
> all modules that are not necessary to boot the box, there is no kvm events
> there. I can see why the host may need them, but not the guest. I'll
> rebuild my guest kernel with kvm events and see if that solves this (but
> that shouldn't be the case).
> 

Just confirmed it. If I add kvm events to the guest, it synchronizes
automatically. Thus, it's a bug to expect the guest to have kvm events, as
there's no reason for them to do so.

-- Steve

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Yordan Karadzhov (VMware)]

On 6.03.20 г. 22:13 ч., Steven Rostedt wrote:
> On Fri,  6 Mar 2020 11:29:00 +0200
> "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:
> 
>> From: "Tzvetomir (VMware)  Stoyanov" <tz.stoyanov@gmail.com>
>>
>> The tracefs library provides APIs for accessing files from tracefs.
>> The library is part of trace-cmd, it is installed as part of trace-cmd
>> installation. KernelShark uses some of those APIs and must be linked with
>> the library
>>
>> Tzvetomir (VMware)  Stoyanov (2):
>>    KernelShark2.0: Link KernelShark to libtracefs
>>    KernelShark2.0: Use libtracefs APIs to access tracefs
>>
> 
> I added these patches to the latest kernelshark-2.0 and it still doesn't
> work for me. I did a little debugging, and noticed that it fails while
> reading the guest trace.dat file with:
> 
> plugin "kvm_combo" failed to initialize on stream /tmp/trace-host-Fedora21.
> 
> It seems to require that the guest trace.dat file has kvm events?

Hi Steven,

Yes it will fail to initialize in the guest's file if it does not 
contain kvm events and this is normal. The plugin only draws the 
additional graphical elements associated with kvm_entry and kvm_exit 
events. So nothing will be plotted on top of the guest data.

The plugin itself has nothing to do with the synchronization of the 
timestamps.

Thanks!
Yordan

> 
> Note, as I build my guest kernel with a make localmodconfig, which disables
> all modules that are not necessary to boot the box, there is no kvm events
> there. I can see why the host may need them, but not the guest. I'll
> rebuild my guest kernel with kvm events and see if that solves this (but
> that shouldn't be the case).
> 
> -- Steve
> 

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Yordan Karadzhov (VMware)]

On 7.03.20 г. 0:34 ч., Steven Rostedt wrote:
> On Fri, 6 Mar 2020 15:13:56 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
>> On Fri,  6 Mar 2020 11:29:00 +0200
>> "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:
>>
>>> From: "Tzvetomir (VMware)  Stoyanov" <tz.stoyanov@gmail.com>
>>>
>>> The tracefs library provides APIs for accessing files from tracefs.
>>> The library is part of trace-cmd, it is installed as part of trace-cmd
>>> installation. KernelShark uses some of those APIs and must be linked with
>>> the library
>>>
>>> Tzvetomir (VMware)  Stoyanov (2):
>>>    KernelShark2.0: Link KernelShark to libtracefs
>>>    KernelShark2.0: Use libtracefs APIs to access tracefs
>>>    
>>
>> I added these patches to the latest kernelshark-2.0 and it still doesn't
>> work for me. I did a little debugging, and noticed that it fails while
>> reading the guest trace.dat file with:
>>
>> plugin "kvm_combo" failed to initialize on stream /tmp/trace-host-Fedora21.
>>
>> It seems to require that the guest trace.dat file has kvm events?
>>
>> Note, as I build my guest kernel with a make localmodconfig, which disables
>> all modules that are not necessary to boot the box, there is no kvm events
>> there. I can see why the host may need them, but not the guest. I'll
>> rebuild my guest kernel with kvm events and see if that solves this (but
>> that shouldn't be the case).
>>
> 
> Just confirmed it. If I add kvm events to the guest, it synchronizes
> automatically. Thus, it's a bug to expect the guest to have kvm events, as
> there's no reason for them to do so.

Is it possible that something else gets enabled during the recording of 
the data, that actually makes the difference?
Y.

> 
> -- Steve
> 

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Steven Rostedt]

On Mon, 9 Mar 2020 11:17:44 +0200
"Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote:

> > Just confirmed it. If I add kvm events to the guest, it synchronizes
> > automatically. Thus, it's a bug to expect the guest to have kvm events, as
> > there's no reason for them to do so.  
> 
> Is it possible that something else gets enabled during the recording of 
> the data, that actually makes the difference?
> Y.

Unfortunately, I blew away the files with the issue and tried to reproduce
it, and I can't :-/

Now even without the kvm events it appears to work. I may try one more
thing (which is to rebuild the guest without KVM at all), and see if I can
bring back the issue. But for now, I guess it's a "WORKS FOR ME" :-/

-- Steve

Re: [PATCH 0/2] KernelShark2.0: Use libtracefs APIs to access tracefs

[Steven Rostedt]

On Mon, 9 Mar 2020 11:44:08 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Now even without the kvm events it appears to work. I may try one more
> thing (which is to rebuild the guest without KVM at all), and see if I can
> bring back the issue. But for now, I guess it's a "WORKS FOR ME" :-/

I still can't reproduce my original issue. Perhaps I did something wrong.
So I guess we can ignore this.

One thing I did notice when testing this, the "all" selection of the KVM
combo plots doesn't seem to work. I have to select each VCPU individually.
Do you see that too?

-- Steve