[PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Steven Rostedt]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Bibo Mao]

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>

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Steven Rostedt]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Bibo Mao]

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
> 

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Huacai Chen]

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
> >
>

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Steven Rostedt]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Steven Rostedt]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Huacai Chen]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Steven Rostedt]

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

Re: [PATCH] LoongArch: KVM: Move kvm_iocsr tracepoint out of generic code

[Huacai Chen]

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
>