arch/loongarch/kvm/trace.h | 35 +++++++++++++++++++++++++++++++++++ include/trace/events/kvm.h | 35 ----------------------------------- 2 files changed, 35 insertions(+), 35 deletions(-)
From: Steven Rostedt <rostedt@goodmis.org>
The tracepoint kvm_iocsr is only used by the loongarch architecture. As
trace events can take up to 5K of memory, move this tracepoint into the
loongarch specific tracing file so that it doesn't waste memory for all
other architectures.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
arch/loongarch/kvm/trace.h | 35 +++++++++++++++++++++++++++++++++++
include/trace/events/kvm.h | 35 -----------------------------------
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/arch/loongarch/kvm/trace.h b/arch/loongarch/kvm/trace.h
index 145514dab6d5..d73dea8afb74 100644
--- a/arch/loongarch/kvm/trace.h
+++ b/arch/loongarch/kvm/trace.h
@@ -115,6 +115,41 @@ TRACE_EVENT(kvm_exit_gspr,
__entry->inst_word)
);
+#define KVM_TRACE_IOCSR_READ_UNSATISFIED 0
+#define KVM_TRACE_IOCSR_READ 1
+#define KVM_TRACE_IOCSR_WRITE 2
+
+#define kvm_trace_symbol_iocsr \
+ { KVM_TRACE_IOCSR_READ_UNSATISFIED, "unsatisfied-read" }, \
+ { KVM_TRACE_IOCSR_READ, "read" }, \
+ { KVM_TRACE_IOCSR_WRITE, "write" }
+
+TRACE_EVENT(kvm_iocsr,
+ TP_PROTO(int type, int len, u64 gpa, void *val),
+ TP_ARGS(type, len, gpa, val),
+
+ TP_STRUCT__entry(
+ __field( u32, type )
+ __field( u32, len )
+ __field( u64, gpa )
+ __field( u64, val )
+ ),
+
+ TP_fast_assign(
+ __entry->type = type;
+ __entry->len = len;
+ __entry->gpa = gpa;
+ __entry->val = 0;
+ if (val)
+ memcpy(&__entry->val, val,
+ min_t(u32, sizeof(__entry->val), len));
+ ),
+
+ TP_printk("iocsr %s len %u gpa 0x%llx val 0x%llx",
+ __print_symbolic(__entry->type, kvm_trace_symbol_iocsr),
+ __entry->len, __entry->gpa, __entry->val)
+);
+
#define KVM_TRACE_AUX_SAVE 0
#define KVM_TRACE_AUX_RESTORE 1
#define KVM_TRACE_AUX_ENABLE 2
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index 8b7252b8d751..b282e3a86769 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -156,41 +156,6 @@ TRACE_EVENT(kvm_mmio,
__entry->len, __entry->gpa, __entry->val)
);
-#define KVM_TRACE_IOCSR_READ_UNSATISFIED 0
-#define KVM_TRACE_IOCSR_READ 1
-#define KVM_TRACE_IOCSR_WRITE 2
-
-#define kvm_trace_symbol_iocsr \
- { KVM_TRACE_IOCSR_READ_UNSATISFIED, "unsatisfied-read" }, \
- { KVM_TRACE_IOCSR_READ, "read" }, \
- { KVM_TRACE_IOCSR_WRITE, "write" }
-
-TRACE_EVENT(kvm_iocsr,
- TP_PROTO(int type, int len, u64 gpa, void *val),
- TP_ARGS(type, len, gpa, val),
-
- TP_STRUCT__entry(
- __field( u32, type )
- __field( u32, len )
- __field( u64, gpa )
- __field( u64, val )
- ),
-
- TP_fast_assign(
- __entry->type = type;
- __entry->len = len;
- __entry->gpa = gpa;
- __entry->val = 0;
- if (val)
- memcpy(&__entry->val, val,
- min_t(u32, sizeof(__entry->val), len));
- ),
-
- TP_printk("iocsr %s len %u gpa 0x%llx val 0x%llx",
- __print_symbolic(__entry->type, kvm_trace_symbol_iocsr),
- __entry->len, __entry->gpa, __entry->val)
-);
-
#define kvm_fpu_load_symbol \
{0, "unload"}, \
{1, "load"}
--
2.47.2
On 2025/7/22 下午9:47, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The tracepoint kvm_iocsr is only used by the loongarch architecture. As
> trace events can take up to 5K of memory, move this tracepoint into the
> loongarch specific tracing file so that it doesn't waste memory for all
> other architectures.
>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> ---
> arch/loongarch/kvm/trace.h | 35 +++++++++++++++++++++++++++++++++++
> include/trace/events/kvm.h | 35 -----------------------------------
> 2 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/arch/loongarch/kvm/trace.h b/arch/loongarch/kvm/trace.h
> index 145514dab6d5..d73dea8afb74 100644
> --- a/arch/loongarch/kvm/trace.h
> +++ b/arch/loongarch/kvm/trace.h
> @@ -115,6 +115,41 @@ TRACE_EVENT(kvm_exit_gspr,
> __entry->inst_word)
> );
>
> +#define KVM_TRACE_IOCSR_READ_UNSATISFIED 0
> +#define KVM_TRACE_IOCSR_READ 1
> +#define KVM_TRACE_IOCSR_WRITE 2
> +
> +#define kvm_trace_symbol_iocsr \
> + { KVM_TRACE_IOCSR_READ_UNSATISFIED, "unsatisfied-read" }, \
> + { KVM_TRACE_IOCSR_READ, "read" }, \
> + { KVM_TRACE_IOCSR_WRITE, "write" }
> +
> +TRACE_EVENT(kvm_iocsr,
> + TP_PROTO(int type, int len, u64 gpa, void *val),
> + TP_ARGS(type, len, gpa, val),
> +
> + TP_STRUCT__entry(
> + __field( u32, type )
> + __field( u32, len )
> + __field( u64, gpa )
> + __field( u64, val )
> + ),
> +
> + TP_fast_assign(
> + __entry->type = type;
> + __entry->len = len;
> + __entry->gpa = gpa;
> + __entry->val = 0;
> + if (val)
> + memcpy(&__entry->val, val,
> + min_t(u32, sizeof(__entry->val), len));
> + ),
> +
> + TP_printk("iocsr %s len %u gpa 0x%llx val 0x%llx",
> + __print_symbolic(__entry->type, kvm_trace_symbol_iocsr),
> + __entry->len, __entry->gpa, __entry->val)
> +);
> +
> #define KVM_TRACE_AUX_SAVE 0
> #define KVM_TRACE_AUX_RESTORE 1
> #define KVM_TRACE_AUX_ENABLE 2
> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> index 8b7252b8d751..b282e3a86769 100644
> --- a/include/trace/events/kvm.h
> +++ b/include/trace/events/kvm.h
> @@ -156,41 +156,6 @@ TRACE_EVENT(kvm_mmio,
> __entry->len, __entry->gpa, __entry->val)
> );
>
> -#define KVM_TRACE_IOCSR_READ_UNSATISFIED 0
> -#define KVM_TRACE_IOCSR_READ 1
> -#define KVM_TRACE_IOCSR_WRITE 2
> -
> -#define kvm_trace_symbol_iocsr \
> - { KVM_TRACE_IOCSR_READ_UNSATISFIED, "unsatisfied-read" }, \
> - { KVM_TRACE_IOCSR_READ, "read" }, \
> - { KVM_TRACE_IOCSR_WRITE, "write" }
> -
> -TRACE_EVENT(kvm_iocsr,
> - TP_PROTO(int type, int len, u64 gpa, void *val),
> - TP_ARGS(type, len, gpa, val),
> -
> - TP_STRUCT__entry(
> - __field( u32, type )
> - __field( u32, len )
> - __field( u64, gpa )
> - __field( u64, val )
> - ),
> -
> - TP_fast_assign(
> - __entry->type = type;
> - __entry->len = len;
> - __entry->gpa = gpa;
> - __entry->val = 0;
> - if (val)
> - memcpy(&__entry->val, val,
> - min_t(u32, sizeof(__entry->val), len));
> - ),
> -
> - TP_printk("iocsr %s len %u gpa 0x%llx val 0x%llx",
> - __print_symbolic(__entry->type, kvm_trace_symbol_iocsr),
> - __entry->len, __entry->gpa, __entry->val)
> -);
> -
> #define kvm_fpu_load_symbol \
> {0, "unload"}, \
> {1, "load"}
>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
On Thu, 24 Jul 2025 09:39:40 +0800
Bibo Mao <maobibo@loongson.cn> wrote:
> > #define kvm_fpu_load_symbol \
> > {0, "unload"}, \
> > {1, "load"}
> >
> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Thanks,
Should this go through the loongarch tree or should I take it?
Either way works for me.
-- Steve
On 2025/7/24 上午9:46, Steven Rostedt wrote:
> On Thu, 24 Jul 2025 09:39:40 +0800
> Bibo Mao <maobibo@loongson.cn> wrote:
>
>>> #define kvm_fpu_load_symbol \
>>> {0, "unload"}, \
>>> {1, "load"}
>>>
>> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
>
> Thanks,
>
> Should this go through the loongarch tree or should I take it?
Huacai,
What is your point about this?
Regards
Bibo Mao
>
> Either way works for me.
>
> -- Steve
>
On Thu, Jul 24, 2025 at 9:51 AM Bibo Mao <maobibo@loongson.cn> wrote:
>
>
>
> On 2025/7/24 上午9:46, Steven Rostedt wrote:
> > On Thu, 24 Jul 2025 09:39:40 +0800
> > Bibo Mao <maobibo@loongson.cn> wrote:
> >
> >>> #define kvm_fpu_load_symbol \
> >>> {0, "unload"}, \
> >>> {1, "load"}
> >>>
> >> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
> >
> > Thanks,
> >
> > Should this go through the loongarch tree or should I take it?
> Huacai,
>
> What is your point about this?
I will take it, thanks.
Huacai
>
> Regards
> Bibo Mao
> >
> > Either way works for me.
> >
> > -- Steve
> >
>
On Thu, 24 Jul 2025 19:56:42 +0800
Huacai Chen <chenhuacai@kernel.org> wrote:
> On Thu, Jul 24, 2025 at 9:51 AM Bibo Mao <maobibo@loongson.cn> wrote:
> >
> >
> >
> > On 2025/7/24 上午9:46, Steven Rostedt wrote:
> > > On Thu, 24 Jul 2025 09:39:40 +0800
> > > Bibo Mao <maobibo@loongson.cn> wrote:
> > >
> > >>> #define kvm_fpu_load_symbol \
> > >>> {0, "unload"}, \
> > >>> {1, "load"}
> > >>>
> > >> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
> > >
> > > Thanks,
> > >
> > > Should this go through the loongarch tree or should I take it?
> > Huacai,
> >
> > What is your point about this?
> I will take it, thanks.
>
> Huacai
Did this fall through the cracks?
-- Steve
On Wed, Aug 20, 2025 at 8:27 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 24 Jul 2025 19:56:42 +0800
> Huacai Chen <chenhuacai@kernel.org> wrote:
>
> > On Thu, Jul 24, 2025 at 9:51 AM Bibo Mao <maobibo@loongson.cn> wrote:
> > >
> > >
> > >
> > > On 2025/7/24 上午9:46, Steven Rostedt wrote:
> > > > On Thu, 24 Jul 2025 09:39:40 +0800
> > > > Bibo Mao <maobibo@loongson.cn> wrote:
> > > >
> > > >>> #define kvm_fpu_load_symbol \
> > > >>> {0, "unload"}, \
> > > >>> {1, "load"}
> > > >>>
> > > >> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
> > > >
> > > > Thanks,
> > > >
> > > > Should this go through the loongarch tree or should I take it?
> > > Huacai,
> > >
> > > What is your point about this?
> > I will take it, thanks.
> >
> > Huacai
>
> Did this fall through the cracks?
I don't know what this means, but I think you are pinging.
This patch appears after I sent the KVM PR for 6.17, and it isn't a
bugfix, so it will go to 6.18.
Huacai
>
> -- Steve
On Wed, 20 Aug 2025 11:03:05 +0800 Huacai Chen <chenhuacai@kernel.org> wrote: > > Did this fall through the cracks? > I don't know what this means, but I think you are pinging. Sorry for the colloquialism, it's not actually the same as a ping. A ping is for something that had no response. This is more about the patch was acknowledged but did not go further. "Falling through the cracks" is like picking a bunch of things up with a bucket that has a crack in it. Some of those things may "fall through the crack" and not be processed. > > This patch appears after I sent the KVM PR for 6.17, and it isn't a > bugfix, so it will go to 6.18. Well, it will start causing warnings soon because it wastes memory. But that will likely begin in 6.18 so we are OK, as long as it gets into linux-next before the warning trigger does. -- Steve
On Wed, Aug 20, 2025 at 9:35 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Wed, 20 Aug 2025 11:03:05 +0800 > Huacai Chen <chenhuacai@kernel.org> wrote: > > > > Did this fall through the cracks? > > I don't know what this means, but I think you are pinging. > > Sorry for the colloquialism, it's not actually the same as a ping. A ping > is for something that had no response. This is more about the patch was > acknowledged but did not go further. "Falling through the cracks" is like > picking a bunch of things up with a bucket that has a crack in it. Some of > those things may "fall through the crack" and not be processed. > > > > This patch appears after I sent the KVM PR for 6.17, and it isn't a > > bugfix, so it will go to 6.18. > > Well, it will start causing warnings soon because it wastes memory. But > that will likely begin in 6.18 so we are OK, as long as it gets into > linux-next before the warning trigger does. Applied, thanks. Huacai > > -- Steve >
On Thu, 24 Jul 2025 19:56:42 +0800 Huacai Chen <chenhuacai@kernel.org> wrote: > > > Should this go through the loongarch tree or should I take it? > > Huacai, > > > > What is your point about this? > I will take it, thanks. Great! Thanks Huacai and Bibo, -- Steve
© 2016 - 2025 Red Hat, Inc.