All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>,
	rostedt <rostedt@goodmis.org>,
	kvm@vger.kernel.org
Subject: [lttng-dev] Unexport of kvm_x86_ops vs tracer modules
Date: Fri, 8 Apr 2022 11:36:26 -0400 (EDT)	[thread overview]
Message-ID: <1218866473.10909.1649432186473.JavaMail.zimbra@efficios.com> (raw)

Hi Sean, Hi Paolo,

I have a question regarding a unexport of kvm_x86_ops that made its
way into 5.18-rc (commit dfc4e6ca04 ("KVM: x86: Unexport kvm_x86_ops").
This is in the context of tracing. Especially, LTTng implements probes
for x86 kvm events, e.g. x86 kvm_exit. It receives a struct kvm_vcpu *
as parameter, and uses kvm_x86_ops.get_exit_info() to translate this
into meaningful fields.

LTTng is an out of tree kernel module, which currently relies on the export.
Indeed, arch/x86/kvm/x86.c exports a set of tracepoints to kernel modules, e.g.:

EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_entry)

But any probe implementation hooking on that tracepoint would need kvm_x86_ops
to translate the struct kvm_vcpu * into meaningful tracing data.

I could work-around this on my side in ugly ways, but I would like to discuss
how kernel module tracers are expected to implement kvm events probes without
the kvm_x86_ops symbol ? Perhaps there is an alternative way to convert the
fields in this structure to meaningful information without using the
kvm_x86_ops callbacks that I am not aware of ?

The LTTng kernel tracer uses get_exit_info() and get_segment_base() callbacks
from kvm_x86_ops.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, rostedt <rostedt@goodmis.org>,
	lttng-dev <lttng-dev@lists.lttng.org>,
	Michael Jeanson <mjeanson@efficios.com>
Subject: Unexport of kvm_x86_ops vs tracer modules
Date: Fri, 8 Apr 2022 11:36:26 -0400 (EDT)	[thread overview]
Message-ID: <1218866473.10909.1649432186473.JavaMail.zimbra@efficios.com> (raw)

Hi Sean, Hi Paolo,

I have a question regarding a unexport of kvm_x86_ops that made its
way into 5.18-rc (commit dfc4e6ca04 ("KVM: x86: Unexport kvm_x86_ops").
This is in the context of tracing. Especially, LTTng implements probes
for x86 kvm events, e.g. x86 kvm_exit. It receives a struct kvm_vcpu *
as parameter, and uses kvm_x86_ops.get_exit_info() to translate this
into meaningful fields.

LTTng is an out of tree kernel module, which currently relies on the export.
Indeed, arch/x86/kvm/x86.c exports a set of tracepoints to kernel modules, e.g.:

EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_entry)

But any probe implementation hooking on that tracepoint would need kvm_x86_ops
to translate the struct kvm_vcpu * into meaningful tracing data.

I could work-around this on my side in ugly ways, but I would like to discuss
how kernel module tracers are expected to implement kvm events probes without
the kvm_x86_ops symbol ? Perhaps there is an alternative way to convert the
fields in this structure to meaningful information without using the
kvm_x86_ops callbacks that I am not aware of ?

The LTTng kernel tracer uses get_exit_info() and get_segment_base() callbacks
from kvm_x86_ops.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

             reply	other threads:[~2022-04-08 15:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 15:36 Mathieu Desnoyers via lttng-dev [this message]
2022-04-08 15:36 ` Unexport of kvm_x86_ops vs tracer modules Mathieu Desnoyers
2022-04-08 16:24 ` [lttng-dev] " Paolo Bonzini via lttng-dev
2022-04-08 16:24   ` Paolo Bonzini
2022-04-08 18:06   ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2022-04-08 18:06     ` Mathieu Desnoyers
2022-04-25 13:00     ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2022-04-25 13:00       ` Mathieu Desnoyers
2022-04-25 13:28       ` Paolo Bonzini via lttng-dev
2022-04-25 13:28         ` Paolo Bonzini
2022-04-25 14:04     ` Steven Rostedt via lttng-dev
2022-04-25 14:04       ` Steven Rostedt
2022-04-25 16:02       ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2022-04-25 16:02         ` Mathieu Desnoyers
2022-04-25 19:13         ` [lttng-dev] " Steven Rostedt via lttng-dev
2022-04-25 19:13           ` Steven Rostedt
2022-04-26  6:36         ` [lttng-dev] " Paolo Bonzini via lttng-dev
2022-04-26  6:36           ` Paolo Bonzini

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=1218866473.10909.1649432186473.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=kvm@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@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.