[PATCH v2 0/2] Improve DIAG 9c observability

[PATCH v2 0/2] Improve DIAG 9c observability

[Ciunas Bennett]

This series enhances observability for DIAG 9c directed yield operations
in s390 KVM by refactoring the handler and adding comprehensive tracing
support.

The first patch refactors __diag_time_slice_end_directed() to use a
single exit point with a result string variable. This consolidates the
control flow and eliminates code duplication in logging statements,
making the function more maintainable.

The second patch builds on this refactoring by adding a new tracepoint
kvm_s390_diag_9c that captures detailed information about directed yield
operations, including source/target VCPU IDs, physical CPU numbers, and
operation results. This enables better analysis of VCPU scheduling
behaviour and helps diagnose performance issues in virtualised s390
environments.

Together, these changes provide kernel developers and system
administrators with better tools to understand and debug VCPU scheduling
patterns related to directed yields.

---
Changes in v2:
 - Add system maintainers to review mail
---

Ciunas Bennett (2):
  s390/kvm: Refactor __diag_time_slice_end_directed for single exit
    point
  s390/kvm: Add tracepoint for DIAG 9c directed yield operations

 arch/s390/kvm/diag.c  | 19 +++++++++++--------
 arch/s390/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+), 8 deletions(-)

base-commit: 184fc1890bcc8242f00fee660d2651290f1461a2
-- 
2.54.0

[PATCH v2 1/2] s390/kvm: Refactor __diag_time_slice_end_directed for single exit point

[Ciunas Bennett]

Refactor the DIAG 9c (directed yield) handler to use a unified exit path,
improving code maintainability and reducing duplication.
Changes:
 - Consolidate all exit paths to use a single 'out' label
 - Replace multiple VCPU_EVENT logging calls with one unified call
 - Introduce 'result' string variable to track operation outcome
 - Initialize tcpu_cpu to -1 for safe handling across all code paths
 - Ensure statistics updates occur before the common exit point

This refactoring maintains identical functionality while making the control
flow clearer and easier to maintain. All three possible outcomes (yield
forwarded, done, ignored) now converge at a single logging point

Signed-off-by: Ciunas Bennett <ciunas@linux.ibm.com>
---
 arch/s390/kvm/diag.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c
index d89d1c381522..85c84421b510 100644
--- a/arch/s390/kvm/diag.c
+++ b/arch/s390/kvm/diag.c
@@ -186,7 +186,8 @@ static int diag9c_forwarding_overrun(void)
 static int __diag_time_slice_end_directed(struct kvm_vcpu *vcpu)
 {
 	struct kvm_vcpu *tcpu;
-	int tcpu_cpu;
+	const char *result;
+	int tcpu_cpu = -1;
 	int tid;
 
 	tid = vcpu->run->s.regs.gprs[(vcpu->arch.sie_block->ipa & 0xf0) >> 4];
@@ -211,21 +212,22 @@ static int __diag_time_slice_end_directed(struct kvm_vcpu *vcpu)
 		if (!vcpu_is_preempted(tcpu_cpu))
 			goto no_yield;
 		smp_yield_cpu(tcpu_cpu);
-		VCPU_EVENT(vcpu, 5,
-			   "diag time slice end directed to %d: yield forwarded",
-			   tid);
 		vcpu->stat.diag_9c_forward++;
-		return 0;
+		result = "yield forwarded";
+		goto out;
 	}
 
 	if (kvm_vcpu_yield_to(tcpu) <= 0)
 		goto no_yield;
 
-	VCPU_EVENT(vcpu, 5, "diag time slice end directed to %d: done", tid);
-	return 0;
+	result = "done";
+	goto out;
 no_yield:
-	VCPU_EVENT(vcpu, 5, "diag time slice end directed to %d: ignored", tid);
 	vcpu->stat.diag_9c_ignored++;
+	result = "ignored";
+out:
+	VCPU_EVENT(vcpu, 5, "diag time slice end directed to %d: %s", tid,
+		   result);
 	return 0;
 }
 
-- 
2.54.0

[PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Ciunas Bennett]

Add a new tracepoint kvm_s390_diag_9c to provide detailed observability
for directed yield operations. The tracepoint captures:
- Source and target VCPU IDs
- Current and target physical CPU numbers
- Operation result (done, ignored, yield forwarded)

This enables better analysis of VCPU scheduling behaviour and helps
diagnose performance issues related to directed yields in virtualised
s390 environments.

Signed-off-by: Ciunas Bennett <ciunas@linux.ibm.com>
---
 arch/s390/kvm/diag.c  |  1 +
 arch/s390/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c
index 85c84421b510..031ab6e5d6c4 100644
--- a/arch/s390/kvm/diag.c
+++ b/arch/s390/kvm/diag.c
@@ -228,6 +228,7 @@ static int __diag_time_slice_end_directed(struct kvm_vcpu *vcpu)
 out:
 	VCPU_EVENT(vcpu, 5, "diag time slice end directed to %d: %s", tid,
 		   result);
+	trace_kvm_s390_diag_9c(vcpu, tid, tcpu_cpu, result);
 	return 0;
 }
 
diff --git a/arch/s390/kvm/trace.h b/arch/s390/kvm/trace.h
index aa419eb6a0c8..2d6da21f590c 100644
--- a/arch/s390/kvm/trace.h
+++ b/arch/s390/kvm/trace.h
@@ -283,6 +283,36 @@ TRACE_EVENT(kvm_s390_handle_diag,
 			   __print_symbolic(__entry->code, diagnose_codes))
 	);
 
+TRACE_EVENT(kvm_s390_diag_9c,
+	    TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
+		     const char *result),
+	    TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
+
+	    TP_STRUCT__entry(
+		    VCPU_FIELD_COMMON
+		    __field(int, target_vcpu)
+		    __field(int, target_cpu)
+		    __field(int, current_cpu)
+		    __string(result, result)
+		    ),
+
+	    TP_fast_assign(
+		    VCPU_ASSIGN_COMMON
+		    __entry->target_vcpu = target_vcpu;
+		    __entry->target_cpu = target_cpu;
+		    __entry->current_cpu = smp_processor_id();
+		    __assign_str(result);
+		    ),
+
+	    VCPU_TP_PRINTK(
+		       "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
+		       __entry->id,
+		       __entry->current_cpu,
+		       __entry->target_vcpu,
+		       __entry->target_cpu,
+		       __get_str(result))
+	);
+
 TRACE_EVENT(kvm_s390_handle_lctl,
 	    TP_PROTO(VCPU_PROTO_COMMON, int g, int reg1, int reg3, u64 addr),
 	    TP_ARGS(VCPU_ARGS_COMMON, g, reg1, reg3, addr),
-- 
2.54.0

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Christian Borntraeger]

Am 25.06.26 um 15:16 schrieb Ciunas Bennett:
> Add a new tracepoint kvm_s390_diag_9c to provide detailed observability
> for directed yield operations. The tracepoint captures:
> - Source and target VCPU IDs
> - Current and target physical CPU numbers
> - Operation result (done, ignored, yield forwarded)
> 
> This enables better analysis of VCPU scheduling behaviour and helps
> diagnose performance issues related to directed yields in virtualised
> s390 environments.

Nothing critical, just some ideas.

> 
> Signed-off-by: Ciunas Bennett <ciunas@linux.ibm.com>
> ---
>   arch/s390/kvm/diag.c  |  1 +
>   arch/s390/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
>   2 files changed, 31 insertions(+)
> 
> diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c
> index 85c84421b510..031ab6e5d6c4 100644
> --- a/arch/s390/kvm/diag.c
> +++ b/arch/s390/kvm/diag.c
> @@ -228,6 +228,7 @@ static int __diag_time_slice_end_directed(struct kvm_vcpu *vcpu)
>   out:
>   	VCPU_EVENT(vcpu, 5, "diag time slice end directed to %d: %s", tid,
>   		   result);
> +	trace_kvm_s390_diag_9c(vcpu, tid, tcpu_cpu, result);
>   	return 0;
>   }
>   
> diff --git a/arch/s390/kvm/trace.h b/arch/s390/kvm/trace.h
> index aa419eb6a0c8..2d6da21f590c 100644
> --- a/arch/s390/kvm/trace.h
> +++ b/arch/s390/kvm/trace.h
> @@ -283,6 +283,36 @@ TRACE_EVENT(kvm_s390_handle_diag,
>   			   __print_symbolic(__entry->code, diagnose_codes))
>   	);
>   
> +TRACE_EVENT(kvm_s390_diag_9c,
> +	    TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
> +		     const char *result),
> +	    TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
> +
> +	    TP_STRUCT__entry(
> +		    VCPU_FIELD_COMMON
> +		    __field(int, target_vcpu)
> +		    __field(int, target_cpu)
> +		    __field(int, current_cpu)
> +		    __string(result, result)
> +		    ),
> +
> +	    TP_fast_assign(
> +		    VCPU_ASSIGN_COMMON
> +		    __entry->target_vcpu = target_vcpu;
> +		    __entry->target_cpu = target_cpu;
> +		    __entry->current_cpu = smp_processor_id();
> +		    __assign_str(result);
> +		    ),
> +
> +	    VCPU_TP_PRINTK(
> +		       "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
> +		       __entry->id,
I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK() already emits as the line prefix; likewise current_cpu/pcpu=%d duplicates ftrace's built-in per-event CPU column.
Can you double check?

> +		       __entry->current_cpu,
> +		       __entry->target_vcpu,
> +		       __entry->target_cpu,
> +		       __get_str(result))

result is a dynamic __string of three fixed literals — an int plus __print_symbolic() (matching diagnose_codes style in the same file) would also allow splitting "ignored", which currently conflates four distinct causes despite the commit's diagnosability goal.
This is not trivial though, due to the VCPU_EVENT which also uses result. So maybe this is not that easy and feel free to ignore that.

> +	);
> +
>   TRACE_EVENT(kvm_s390_handle_lctl,
>   	    TP_PROTO(VCPU_PROTO_COMMON, int g, int reg1, int reg3, u64 addr),
>   	    TP_ARGS(VCPU_ARGS_COMMON, g, reg1, reg3, addr),

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Ciunas Bennett]

On 23/07/2026 16:28, Christian Borntraeger wrote:
>

[...]

>> +TRACE_EVENT(kvm_s390_diag_9c,
>> +        TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
>> +             const char *result),
>> +        TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
>> +
>> +        TP_STRUCT__entry(
>> +            VCPU_FIELD_COMMON
>> +            __field(int, target_vcpu)
>> +            __field(int, target_cpu)
>> +            __field(int, current_cpu)
>> +            __string(result, result)
>> +            ),
>> +
>> +        TP_fast_assign(
>> +            VCPU_ASSIGN_COMMON
>> +            __entry->target_vcpu = target_vcpu;
>> +            __entry->target_cpu = target_cpu;
>> +            __entry->current_cpu = smp_processor_id();
>> +            __assign_str(result);
>> +            ),
>> +
>> +        VCPU_TP_PRINTK(
>> +               "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
>> +               __entry->id,
> I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK() already emits as the line prefix; likewise current_cpu/pcpu=%d duplicates ftrace's built-in per-event CPU column.
> Can you double check?

Yes it is and I was aware that VCPU_TP_PRINTK already includes the vCPU ID
in the prefix, but I kept it in the message for readability.
Having all the relevant fields together in a single format string makes
the output a bit easier to grep and follow visually I find.
That said, if you'd prefer to keep it consistent with the other
tracepoints, I'm happy to drop the duplicate vCPU field.

> 
>> +               __entry->current_cpu,
>> +               __entry->target_vcpu,
>> +               __entry->target_cpu,
>> +               __get_str(result))
> 
> result is a dynamic __string of three fixed literals — an int plus __print_symbolic() (matching diagnose_codes style in the same file) would also allow splitting "ignored", which currently conflates four distinct causes despite the commit's diagnosability goal.
> This is not trivial though, due to the VCPU_EVENT which also uses result. So maybe this is not that easy and feel free to ignore that.
>
I'm not against changing it to an int plus __print_symbolic() if you
think that is worth doing?
The hesitation is of course that VCPU_EVENT() cannot use __print_symbolic()
directly, so this would also need a small helper to map the result code
back to a string there. That means a bit more code for fairly limited
value in this case.
No issues to change it if you think it is worthwhile, but otherwise
I'd prefer to keep the current version and avoid the extra helper.

[...]

Ciunas

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Sven Schnelle]

Ciunas Bennett <ciunas@linux.ibm.com> writes:

> On 23/07/2026 16:28, Christian Borntraeger wrote:
>>
>
> [...]
>
>>> +TRACE_EVENT(kvm_s390_diag_9c,
>>> +        TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
>>> +             const char *result),
>>> +        TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
>>> +
>>> +        TP_STRUCT__entry(
>>> +            VCPU_FIELD_COMMON
>>> +            __field(int, target_vcpu)
>>> +            __field(int, target_cpu)
>>> +            __field(int, current_cpu)
>>> +            __string(result, result)
>>> +            ),
>>> +
>>> +        TP_fast_assign(
>>> +            VCPU_ASSIGN_COMMON
>>> +            __entry->target_vcpu = target_vcpu;
>>> +            __entry->target_cpu = target_cpu;
>>> +            __entry->current_cpu = smp_processor_id();
>>> +            __assign_str(result);
>>> +            ),
>>> +
>>> +        VCPU_TP_PRINTK(
>>> +               "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
>>> +               __entry->id,
>> I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK()
>> already emits as the line prefix; likewise current_cpu/pcpu=%d
>> duplicates ftrace's built-in per-event CPU column.
>> Can you double check?
>
> Yes it is and I was aware that VCPU_TP_PRINTK already includes the vCPU ID
> in the prefix, but I kept it in the message for readability.
> Having all the relevant fields together in a single format string makes
> the output a bit easier to grep and follow visually I find.
> That said, if you'd prefer to keep it consistent with the other
> tracepoints, I'm happy to drop the duplicate vCPU field.

Please drop it - it should be consistent with other tracepoint, and
would only consume additional space in the trace buffer.

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Christian Borntraeger]

Am 23.07.26 um 21:56 schrieb Ciunas Bennett:
> 
> 
> On 23/07/2026 16:28, Christian Borntraeger wrote:
>>
> 
> [...]
> 
>>> +TRACE_EVENT(kvm_s390_diag_9c,
>>> +        TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
>>> +             const char *result),
>>> +        TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
>>> +
>>> +        TP_STRUCT__entry(
>>> +            VCPU_FIELD_COMMON
>>> +            __field(int, target_vcpu)
>>> +            __field(int, target_cpu)
>>> +            __field(int, current_cpu)
>>> +            __string(result, result)
>>> +            ),
>>> +
>>> +        TP_fast_assign(
>>> +            VCPU_ASSIGN_COMMON
>>> +            __entry->target_vcpu = target_vcpu;
>>> +            __entry->target_cpu = target_cpu;
>>> +            __entry->current_cpu = smp_processor_id();
>>> +            __assign_str(result);
>>> +            ),
>>> +
>>> +        VCPU_TP_PRINTK(
>>> +               "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
>>> +               __entry->id,
>> I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK() already emits as the line prefix; likewise current_cpu/pcpu=%d duplicates ftrace's built-in per-event CPU column.
>> Can you double check?
> 
> Yes it is and I was aware that VCPU_TP_PRINTK already includes the vCPU ID
> in the prefix, but I kept it in the message for readability.
> Having all the relevant fields together in a single format string makes
> the output a bit easier to grep and follow visually I find.
> That said, if you'd prefer to keep it consistent with the other
> tracepoints, I'm happy to drop the duplicate vCPU field.

Yes, please drop.> 
>>
>>> +               __entry->current_cpu,
>>> +               __entry->target_vcpu,
>>> +               __entry->target_cpu,
>>> +               __get_str(result))
>>
>> result is a dynamic __string of three fixed literals — an int plus __print_symbolic() (matching diagnose_codes style in the same file) would also allow splitting "ignored", which currently conflates four distinct causes despite the commit's diagnosability goal.
>> This is not trivial though, due to the VCPU_EVENT which also uses result. So maybe this is not that easy and feel free to ignore that.
>>
> I'm not against changing it to an int plus __print_symbolic() if you
> think that is worth doing?
> The hesitation is of course that VCPU_EVENT() cannot use __print_symbolic()
> directly, so this would also need a small helper to map the result code
> back to a string there. That means a bit more code for fairly limited
> value in this case.
> No issues to change it if you think it is worthwhile, but otherwise
> I'd prefer to keep the current version and avoid the extra helper.

Keep it as is.
Thank you for doing this.

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Ciunas Bennett]

On 24/07/2026 09:03, Christian Borntraeger wrote:
> 
> 
> Am 23.07.26 um 21:56 schrieb Ciunas Bennett:
>>
>>
>> On 23/07/2026 16:28, Christian Borntraeger wrote:
>>>
>>
>> [...]
>>
>>>> +TRACE_EVENT(kvm_s390_diag_9c,
>>>> +        TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
>>>> +             const char *result),
>>>> +        TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
>>>> +
>>>> +        TP_STRUCT__entry(
>>>> +            VCPU_FIELD_COMMON
>>>> +            __field(int, target_vcpu)
>>>> +            __field(int, target_cpu)
>>>> +            __field(int, current_cpu)
>>>> +            __string(result, result)
>>>> +            ),
>>>> +
>>>> +        TP_fast_assign(
>>>> +            VCPU_ASSIGN_COMMON
>>>> +            __entry->target_vcpu = target_vcpu;
>>>> +            __entry->target_cpu = target_cpu;
>>>> +            __entry->current_cpu = smp_processor_id();
>>>> +            __assign_str(result);
>>>> +            ),
>>>> +
>>>> +        VCPU_TP_PRINTK(
>>>> +               "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
>>>> +               __entry->id,
>>> I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK() already emits as the line prefix; likewise current_cpu/pcpu=%d duplicates ftrace's built-in per-event CPU column.
>>> Can you double check?
>>
>> Yes it is and I was aware that VCPU_TP_PRINTK already includes the vCPU ID
>> in the prefix, but I kept it in the message for readability.
>> Having all the relevant fields together in a single format string makes
>> the output a bit easier to grep and follow visually I find.
>> That said, if you'd prefer to keep it consistent with the other
>> tracepoints, I'm happy to drop the duplicate vCPU field.
> 
> Yes, please drop.>

Just to quickly follow up on this: ftrace already prints both the vcpu and the pcpu, as shown in the output below.
In that case, would you like me to remove both of them and keep only target_vcpu and target_pcpu?

[CPU 7/KVM-2066    [017] .....   827.871131: kvm_s390_diag_9c: 07[0404c00180000000-000001e619a6a9ea]: diag=9c vcpu=7 pcpu=17 target_vcpu=1 target_pcpu=23 result=ignored]

[...] Ciunas

Re: [PATCH v2 2/2] s390/kvm: Add tracepoint for DIAG 9c directed yield operations

[Christian Borntraeger]

Am 24.07.26 um 11:00 schrieb Ciunas Bennett:
> 
> 
> On 24/07/2026 09:03, Christian Borntraeger wrote:
>>
>>
>> Am 23.07.26 um 21:56 schrieb Ciunas Bennett:
>>>
>>>
>>> On 23/07/2026 16:28, Christian Borntraeger wrote:
>>>>
>>>
>>> [...]
>>>
>>>>> +TRACE_EVENT(kvm_s390_diag_9c,
>>>>> +        TP_PROTO(VCPU_PROTO_COMMON, int target_vcpu, int target_cpu,
>>>>> +             const char *result),
>>>>> +        TP_ARGS(VCPU_ARGS_COMMON, target_vcpu, target_cpu, result),
>>>>> +
>>>>> +        TP_STRUCT__entry(
>>>>> +            VCPU_FIELD_COMMON
>>>>> +            __field(int, target_vcpu)
>>>>> +            __field(int, target_cpu)
>>>>> +            __field(int, current_cpu)
>>>>> +            __string(result, result)
>>>>> +            ),
>>>>> +
>>>>> +        TP_fast_assign(
>>>>> +            VCPU_ASSIGN_COMMON
>>>>> +            __entry->target_vcpu = target_vcpu;
>>>>> +            __entry->target_cpu = target_cpu;
>>>>> +            __entry->current_cpu = smp_processor_id();
>>>>> +            __assign_str(result);
>>>>> +            ),
>>>>> +
>>>>> +        VCPU_TP_PRINTK(
>>>>> +               "diag=9c vcpu=%d pcpu=%d target_vcpu=%d target_pcpu=%d result=%s",
>>>>> +               __entry->id,
>>>> I think vcpu=%d re-prints __entry->id, which VCPU_TP_PRINTK() already emits as the line prefix; likewise current_cpu/pcpu=%d duplicates ftrace's built-in per-event CPU column.
>>>> Can you double check?
>>>
>>> Yes it is and I was aware that VCPU_TP_PRINTK already includes the vCPU ID
>>> in the prefix, but I kept it in the message for readability.
>>> Having all the relevant fields together in a single format string makes
>>> the output a bit easier to grep and follow visually I find.
>>> That said, if you'd prefer to keep it consistent with the other
>>> tracepoints, I'm happy to drop the duplicate vCPU field.
>>
>> Yes, please drop.>
> 
> Just to quickly follow up on this: ftrace already prints both the vcpu and the pcpu, as shown in the output below.
> In that case, would you like me to remove both of them and keep only target_vcpu and target_pcpu?
> 
> [CPU 7/KVM-2066    [017] .....   827.871131: kvm_s390_diag_9c: 07[0404c00180000000-000001e619a6a9ea]: diag=9c vcpu=7 pcpu=17 target_vcpu=1 target_pcpu=23 result=ignored]

Its a bit harder to read, but yes try to avoid redundancy.

Re: [PATCH v2 0/2] Improve DIAG 9c observability

[Mete Durlu]

On 6/25/26 3:16 PM, Ciunas Bennett wrote:
> This series enhances observability for DIAG 9c directed yield operations
> in s390 KVM by refactoring the handler and adding comprehensive tracing
> support.
> 
> The first patch refactors __diag_time_slice_end_directed() to use a
> single exit point with a result string variable. This consolidates the
> control flow and eliminates code duplication in logging statements,
> making the function more maintainable.
> 
> The second patch builds on this refactoring by adding a new tracepoint
> kvm_s390_diag_9c that captures detailed information about directed yield
> operations, including source/target VCPU IDs, physical CPU numbers, and
> operation results. This enables better analysis of VCPU scheduling
> behaviour and helps diagnose performance issues in virtualised s390
> environments.
> 
> Together, these changes provide kernel developers and system
> administrators with better tools to understand and debug VCPU scheduling
> patterns related to directed yields.
> 
> ---
> Changes in v2:
>   - Add system maintainers to review mail
> ---
> 
> Ciunas Bennett (2):
>    s390/kvm: Refactor __diag_time_slice_end_directed for single exit
>      point
>    s390/kvm: Add tracepoint for DIAG 9c directed yield operations
> 
>   arch/s390/kvm/diag.c  | 19 +++++++++++--------
>   arch/s390/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
>   2 files changed, 41 insertions(+), 8 deletions(-)
> 
> base-commit: 184fc1890bcc8242f00fee660d2651290f1461a2

I gave the patches a quick spin using a single kvm guest.

Both VCPU_EVENTs and ftrace events works well.

Tested-by: Mete Durlu <meted@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>

Re: [PATCH v2 0/2] Improve DIAG 9c observability

[Claudio Imbrenda]

On Thu, 25 Jun 2026 15:16:13 +0200
Ciunas Bennett <ciunas@linux.ibm.com> wrote:

> This series enhances observability for DIAG 9c directed yield operations
> in s390 KVM by refactoring the handler and adding comprehensive tracing
> support.
> 
> The first patch refactors __diag_time_slice_end_directed() to use a
> single exit point with a result string variable. This consolidates the
> control flow and eliminates code duplication in logging statements,
> making the function more maintainable.
> 
> The second patch builds on this refactoring by adding a new tracepoint
> kvm_s390_diag_9c that captures detailed information about directed yield
> operations, including source/target VCPU IDs, physical CPU numbers, and
> operation results. This enables better analysis of VCPU scheduling
> behaviour and helps diagnose performance issues in virtualised s390
> environments.
> 
> Together, these changes provide kernel developers and system
> administrators with better tools to understand and debug VCPU scheduling
> patterns related to directed yields.
> 
> ---
> Changes in v2:
>  - Add system maintainers to review mail
> ---

whole series:

Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com>

> 
> Ciunas Bennett (2):
>   s390/kvm: Refactor __diag_time_slice_end_directed for single exit
>     point
>   s390/kvm: Add tracepoint for DIAG 9c directed yield operations
> 
>  arch/s390/kvm/diag.c  | 19 +++++++++++--------
>  arch/s390/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 41 insertions(+), 8 deletions(-)
> 
> base-commit: 184fc1890bcc8242f00fee660d2651290f1461a2