lkml.org 
[lkml]   [2020]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/7] KVM: x86: Use common definition for kvm_nested_vmexit tracepoint
On Tue, 21 Jul 2020 12:31:30 -0700
Sean Christopherson <sean.j.christopherson@intel.com> wrote:

> +Steve
>
> Background: KVM has two tracepoints that effectively trace the same thing
> (VM-Exit vs. nested VM-Exit), but use completely different formatting and
> nomenclature for each of the existing tracepoints. I want to add a common
> macro to create the tracepoints so that they capture the exact same info
> and report it with the exact same format. But that means breaking the
> "ABI" for one of the tracepoints, e.g. trace-cmd barfs on the rename of
> exit_code to exit_reason.

Feel free to update it.

>
> Was there ever a verdict on whether or not tracepoints are considered ABI
> and thus must retain backwards compatibility?
>
> If not, what's the proper way to upstream changes to trace-cmd?
>

There's a kvm plugin in the libtraceevent code.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/traceevent/plugins/plugin_kvm.c

This overrides how the events are read. In the callback handler
(e.g. kvm_nested_vmexit_handle()), you can test if "rip" is there or
not. If it is not, you can do something different. For example:

struct tep_format_field *field;

field = tep_find_any_field(event, "rip");
if (field) {
tep_print_num_field(s, "rip %llx ", event, "rip", record, 1)
[..]
} else {
/* do something new */
}

You can test if fields exist and have the plugins do different things
depending on the format of an event. This is what I do in case an event
changes in the future.

-- Steve

\
 
 \ /
  Last update: 2020-07-21 23:43    [W:0.108 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site