All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Junichi Uekawa (上川純一)" <uekawa@google.com>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: trace-cmd report: Add callback for kvm plugin to show guest functions
Date: Wed, 28 Sep 2022 08:17:04 -0400	[thread overview]
Message-ID: <20220928081704.74d22a2d@gandalf.local.home> (raw)
In-Reply-To: <CADgJSGEoELCWYYxsRJaMK9egCUhbRV7QWEqTga71tAC-GR8qeA@mail.gmail.com>

On Wed, 28 Sep 2022 09:24:14 +0900
Junichi Uekawa (上川純一) <uekawa@google.com> wrote:

> +
> +
> +const char *tep_plugin_kvm_get_func(struct tep_event *event,
> +                                   struct tep_record *record,
> +                                   unsigned long long *val)
> +{
> 
> I think this could be implemented in a .so plugin that is dlopen()'d which might be more intuitive (along with the others).
> I think using dlopen RTLD_GLOBAL will use the symbols instead of the weak symbols (but I need to check if that was the actual behavior).

So we should have a dlopen on an .so from this .so that is dlopen()ed?

The issue here is that libtraceevent has several .so plugins loaded with
dlopen(). One of them is the plugin_kvm.so, which needs a way to translate
the rip that the host receives with the function it maps to in the guest.
The issue is that the libtraceevent only handles one set of tracing data,
and that's for just the host. Now because plugin_kvm.so is a plugin, it
only interacts with libtraceevent.

Now we could add a call to libtraceeveent that is
"tep_load_guest_mappings()" but then we need to make it so that it can load
several guest mappings, and the place in the plugin_kvm.so will need to
also know what guest it is for.

In which case I feel it is losing the scope of what libtraceevent is for
(just parsing of the event's raw data). Which is why I added this hack.

Or maybe I misunderstood what you were suggesting.

-- Steve


>  
> +       struct tep_handle *tep;
> +       struct kvm_cpu_map *map;
> +       struct kvm_cpu_map key;
> +       unsigned long long rip = *val;
> +       const char *func;
> +       int pid;

      parent reply	other threads:[~2022-09-28 12:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  0:26 trace-cmd report: Add callback for kvm plugin to show guest functions Steven Rostedt
     [not found] ` <CADgJSGEoELCWYYxsRJaMK9egCUhbRV7QWEqTga71tAC-GR8qeA@mail.gmail.com>
2022-09-28 12:17   ` Steven Rostedt [this message]

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=20220928081704.74d22a2d@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=uekawa@google.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.