From: Vincent Donnefort <vdonnefort@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
linux-trace-kernel@vger.kernel.org, maz@kernel.org,
oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
jstultz@google.com, qperret@google.com, will@kernel.org,
aneesh.kumar@kernel.org, kernel-team@android.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 03/24] tracing: Introduce trace remotes
Date: Tue, 9 Sep 2025 13:08:28 +0100 [thread overview]
Message-ID: <aMAYvA9LSvfxvt_C@google.com> (raw)
In-Reply-To: <20250908193606.47143d09@gandalf.local.home>
On Mon, Sep 08, 2025 at 07:36:05PM -0400, Steven Rostedt wrote:
> On Thu, 21 Aug 2025 09:13:51 +0100
> Vincent Donnefort <vdonnefort@google.com> wrote:
>
> > A trace remote relies on ring-buffer remotes to read and control
> > compatible tracing buffers, written by entity such as firmware or
> > hypervisor.
> >
> > Add a Tracefs directory remotes/ that contains all instances of trace
> > remotes. Each instance follows the same hierarchy as any other to ease
> > the support by existing user-space tools.
> >
> > This currently does not provide any event support, which will come
> > later.
> >
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/include/linux/trace_remote.h b/include/linux/trace_remote.h
> > new file mode 100644
> > index 000000000000..de043a6f2fe0
> > --- /dev/null
> > +++ b/include/linux/trace_remote.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef _LINUX_TRACE_REMOTE_H
> > +#define _LINUX_TRACE_REMOTE_H
> > +
> > +#include <linux/ring_buffer.h>
> > +
> > +struct trace_remote_callbacks {
> > + struct trace_buffer_desc *
> > + (*load_trace_buffer)(unsigned long size, void *priv);
>
> I believe this is one of those cases where the 80 char limit is more of a
> guildline than a rule. It looks better to keep the above as one line.
>
> > + void (*unload_trace_buffer)(struct trace_buffer_desc *desc, void *priv);
>
> Heck, this is already passed 80 characters ;-)
>
> > + int (*enable_tracing)(bool enable, void *priv);
> > + int (*swap_reader_page)(unsigned int cpu, void *priv);
> > +};
> > +
> > +int trace_remote_register(const char *name, struct trace_remote_callbacks *cbs, void *priv);
> > +int trace_remote_alloc_buffer(struct trace_buffer_desc *desc, size_t size,
> > + const struct cpumask *cpumask);
> > +void trace_remote_free_buffer(struct trace_buffer_desc *desc);
> > +
> > +#endif
> > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > index d2c79da81e4f..99af56d39eaf 100644
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
> > @@ -1238,4 +1238,7 @@ config HIST_TRIGGERS_DEBUG
> >
>
>
> > +
> > +int trace_remote_register(const char *name, struct trace_remote_callbacks *cbs, void *priv)
> > +{
> > + struct trace_remote *remote;
> > +
> > + remote = kzalloc(sizeof(*remote), GFP_KERNEL);
> > + if (!remote)
> > + return -ENOMEM;
> > +
> > + remote->cbs = cbs;
> > + remote->priv = priv;
> > + remote->trace_buffer_size = 7 << 10;
> > + remote->poll_ms = 100;
>
> What's with the magic numbers?
The 7KiB value can be modified with the tracefs file buffer_size_kb.
the 100ms can't be modified. I could either make a tracefs file or just a
trace_remote_set_poll_ms() function so it can be modified after registration.
In all cases, I'll add a TRACE_REMOTE_DEFAULT_XXXX definition at the start of
the file.
>
> > + mutex_init(&remote->lock);
> > +
> > + if (trace_remote_init_tracefs(name, remote)) {
> > + kfree(remote);
> > + return -ENOMEM;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +void trace_remote_free_buffer(struct trace_buffer_desc *desc)
> > +{
> > + struct ring_buffer_desc *rb_desc;
> > + int cpu;
> > +
> > + for_each_ring_buffer_desc(rb_desc, cpu, desc) {
> > + unsigned int id;
> > +
> > + free_page(rb_desc->meta_va);
> > +
> > + for (id = 0; id < rb_desc->nr_page_va; id++)
> > + free_page(rb_desc->page_va[id]);
> > + }
> > +}
> > +
> > +int trace_remote_alloc_buffer(struct trace_buffer_desc *desc, size_t size,
> > + const struct cpumask *cpumask)
> > +{
> > + int nr_pages = (PAGE_ALIGN(size) / PAGE_SIZE) + 1;
> > + struct ring_buffer_desc *rb_desc;
> > + int cpu;
> > +
> > + desc->nr_cpus = 0;
> > + desc->struct_len = offsetof(struct trace_buffer_desc, __data);
>
> The above is better as:
>
> desc->struct_len = struct_size(desc, __data, 0);
>
> As it also does some other checks, like make sure __data is a flexible
> array.
>
> > +
> > + rb_desc = (struct ring_buffer_desc *)&desc->__data[0];
> > +
> > + for_each_cpu(cpu, cpumask) {
> > + unsigned int id;
> > +
> > + rb_desc->cpu = cpu;
> > + rb_desc->nr_page_va = 0;
> > + rb_desc->meta_va = (unsigned long)__get_free_page(GFP_KERNEL);
> > + if (!rb_desc->meta_va)
> > + goto err;
> > +
> > + for (id = 0; id < nr_pages; id++) {
> > + rb_desc->page_va[id] = (unsigned long)__get_free_page(GFP_KERNEL);
> > + if (!rb_desc->page_va[id])
>
> What exactly are these pages allocated for? Is this what the remote will
> use to write to? There should be more comments about how this is used.
Those are the actual ring-buffer data pages. I'll add a comment here.
>
> > + goto err;
> > +
> > + rb_desc->nr_page_va++;
> > + }
> > + desc->nr_cpus++;
> > + desc->struct_len += offsetof(struct ring_buffer_desc, page_va);
> > + desc->struct_len += sizeof(rb_desc->page_va[0]) * rb_desc->nr_page_va;
>
> Shouldn't the above be:
>
> desc->struct_len += struct_size(rb_desc, page_va, rb_desc->nr_page_va);
>
> ?
Yes, that'd look way better.
>
> > + rb_desc = __next_ring_buffer_desc(rb_desc);
>
> Is there no check to make sure that the cpu mask matches what the rb_desc
> will have?
The function is filling rb_desc[], based on the cpumask input, so both will
match when returning from this function.
It is then easy to handle the case where some CPUs are not part of the cpumask.
See remote_test_load() where for_each_ring_buffer_desc() iterates over all the
CPUs from the trace_desc but uses rb_desc->cpu.
Is it what you meant?
>
> -- Steve
>
> > + }
> > +
> > + return 0;
> > +
> > +err:
> > + trace_remote_free_buffer(desc);
> > + return -ENOMEM;
> > +}
>
next prev parent reply other threads:[~2025-09-09 17:17 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 8:13 [PATCH v6 00/24] Tracefs support for pKVM Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 01/24] ring-buffer: Add page statistics to the meta-page Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 02/24] ring-buffer: Introduce ring-buffer remotes Vincent Donnefort
2025-09-08 23:13 ` Steven Rostedt
2025-08-21 8:13 ` [PATCH v6 03/24] tracing: Introduce trace remotes Vincent Donnefort
2025-09-08 23:36 ` Steven Rostedt
2025-09-09 12:08 ` Vincent Donnefort [this message]
2025-09-09 13:38 ` Steven Rostedt
2025-09-09 16:10 ` Vincent Donnefort
2025-09-09 18:19 ` Steven Rostedt
2025-08-21 8:13 ` [PATCH v6 04/24] tracing: Add reset to " Vincent Donnefort
2025-09-08 23:37 ` Steven Rostedt
2025-09-09 12:10 ` Vincent Donnefort
2025-09-09 13:40 ` Steven Rostedt
2025-09-09 16:14 ` Vincent Donnefort
2025-09-09 18:39 ` Steven Rostedt
2025-09-09 18:52 ` Steven Rostedt
2025-09-10 9:45 ` Vincent Donnefort
2025-09-10 16:45 ` Steven Rostedt
2025-08-21 8:13 ` [PATCH v6 05/24] tracing: Add init callback " Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 06/24] tracing: Add events " Vincent Donnefort
2025-09-09 21:47 ` Steven Rostedt
2025-09-09 22:24 ` Steven Rostedt
2025-08-21 8:13 ` [PATCH v6 07/24] tracing: Add events/ root files " Vincent Donnefort
2025-09-09 21:52 ` Steven Rostedt
2025-08-21 8:13 ` [PATCH v6 08/24] tracing: Add helpers to create trace remote events Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 09/24] ring-buffer: Export buffer_data_page and macros Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 10/24] tracing: Introduce simple_ring_buffer Vincent Donnefort
2025-09-09 22:26 ` Steven Rostedt
2025-09-10 9:47 ` Vincent Donnefort
2025-08-21 8:13 ` [PATCH v6 11/24] tracing: Add a trace remote module for testing Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 12/24] tracing: selftests: Add trace remote tests Vincent Donnefort
2025-09-03 4:58 ` Masami Hiramatsu
2025-08-21 8:14 ` [PATCH v6 13/24] tracing: load/unload page callbacks for simple_ring_buffer Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 14/24] tracing: Check for undefined symbols in simple_ring_buffer Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 15/24] KVM: arm64: Support unaligned fixmap in the pKVM hyp Vincent Donnefort
2025-09-10 16:47 ` Steven Rostedt
2025-09-10 17:06 ` Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 16/24] KVM: arm64: Add clock support for " Vincent Donnefort
2025-09-12 13:48 ` Will Deacon
2025-08-21 8:14 ` [PATCH v6 17/24] KVM: arm64: Add tracing capability " Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 18/24] KVM: arm64: Add trace remote " Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 19/24] KVM: arm64: Sync boot clock with " Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 20/24] KVM: arm64: Add trace reset to " Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 21/24] KVM: arm64: Add event support to the pKVM hyp and trace remote Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 22/24] KVM: arm64: Add hyp_enter/hyp_exit events to pKVM hyp Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 23/24] KVM: arm64: Add selftest event support " Vincent Donnefort
2025-08-21 8:14 ` [PATCH v6 24/24] tracing: selftests: Add pKVM trace remote tests Vincent Donnefort
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=aMAYvA9LSvfxvt_C@google.com \
--to=vdonnefort@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=joey.gouly@arm.com \
--cc=jstultz@google.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=maz@kernel.org \
--cc=mhiramat@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).