Re: [PATCH] KVM: x86: Add tracepoint for vCPU wait/yield paths

[Sean Christopherson <seanjc@google.com>]

On Fri, May 22, 2026, zhanghao wrote:
> On Thu, May 21, 2026, Sean Christopherson wrote:
> > On Thu, May 21, 2026, zhanghao wrote:
> > > >From 0c8d4428390a1238a956f713c1ddced18eac83da Mon Sep 17 00:00:00 2001
> > > From: Hao Zhang <zhanghao1@kylinos.cn>
> > > Date: Thu, 21 May 2026 16:30:37 +0800
> > > 
> > > Add a KVM x86 tracepoint that reports when a vCPU reaches selected
> > > wait/yield handling paths in KVM.
> > 
> > Why?
> 
> The intent is not to add a scheduling policy hook, but to expose a single
> observability point for KVM paths that already have wait/yield semantics.
> 
> Today userspace can infer parts of this from lower-level tracepoints, but
> only by stitching together different sources:
> 
>   - PLE can be inferred from VMX/SVM exit reasons via kvm_exit.
>   - KVM_HC_SCHED_YIELD can be inferred from kvm_hypercall.
>   - Hyper-V and Xen yield/spin-wait paths have their own hypercall paths.
>   - HLT may not be visible as a userspace exit when KVM handles the halt
>     internally, e.g. with in-kernel LAPIC.
> 
> Those tracepoints are useful, but they expose lower-level mechanisms rather
> than the KVM-level point where the vCPU reaches an existing wait/yield
> handling path.  Consumers that want to correlate vCPU wait/yield behavior
> with host scheduling activity currently need to understand VMX vs. SVM exit
> encoding, native KVM hypercall arguments, Hyper-V/Xen hypercall semantics,
> and HLT handling differences.
> 
> This tracepoint is meant to provide that common KVM-level signal:
> 
>   - ple: KVM reached the PLE handling path
>   - hlt: KVM emulated a guest HLT
>   - pv_yield: KVM reached a paravirtual yield-style path
> 
> The tracepoint is informational only.  It does not change KVM scheduling
> behavior, directed-yield behavior, vCPU placement, or host scheduler state.
> The target field is also only the guest-supplied value when one exists; it
> does not imply that the target exists, is runnable, or that a directed yield
> succeeded.
> 
> So the reason for adding a new tracepoint is to avoid requiring userspace
> observability tools to reconstruct this higher-level wait/yield signal from
> several unrelated low-level tracepoints and architecture-specific details.

Tracepoints aren't ABI though, and "observability tools" suggest userspace wants
to build functionality on top of all of this.  If this is for debug purposes,
then tools like bpftrace are a much better option.