Re: [PATCH v9 29/30] KVM: arm64: Add selftest event support to nVHE/pKVM hyp
From: Vincent Donnefort <hidden>
Date: 2026-01-23 12:14:39
Also in:
kvmarm, linux-arm-kernel, lkml
On Wed, Jan 07, 2026 at 03:40:22PM +0000, Marc Zyngier wrote:
On Tue, 02 Dec 2025 09:36:22 +0000, Vincent Donnefort [off-list ref] wrote:quoted
Add a selftest event that can be triggered from a `write_event` tracefs file. This intends to be used by trace remote selftests. Signed-off-by: Vincent Donnefort <redacted>diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h index 37c015b54ff6..e2de7ad64938 100644 --- a/arch/arm64/include/asm/kvm_asm.h +++ b/arch/arm64/include/asm/kvm_asm.h@@ -96,6 +96,7 @@ enum __kvm_host_smccc_func { __KVM_HOST_SMCCC_FUNC___tracing_update_clock, __KVM_HOST_SMCCC_FUNC___tracing_reset, __KVM_HOST_SMCCC_FUNC___tracing_enable_event, + __KVM_HOST_SMCCC_FUNC___tracing_write_event, }; #define DECLARE_KVM_VHE_SYM(sym) extern char sym[]diff --git a/arch/arm64/include/asm/kvm_hypevents.h b/arch/arm64/include/asm/kvm_hypevents.h index 268b3cd7a1b2..c276fd28e0bf 100644 --- a/arch/arm64/include/asm/kvm_hypevents.h +++ b/arch/arm64/include/asm/kvm_hypevents.h@@ -42,4 +42,15 @@ HYP_EVENT(hyp_exit, ), HE_PRINTK("reason=%s", __hyp_enter_exit_reason_str(__entry->reason)) ); + +HYP_EVENT(selftest, + HE_PROTO(u64 id), + HE_STRUCT( + he_field(u64, id) + ), + HE_ASSIGN( + __entry->id = id; + ), + RE_PRINTK("id=%llu", __entry->id)Not strictly related to this patch, but I find that the trace itself lacks context. For example: [001] 323.847422: hyp_enter reason=hvc [001] 323.847423: hyp_exit reason=eret_host [001] 323.847688: hyp_enter reason=hvc [001] 323.847688: hyp_exit reason=eret_host [001] 323.847706: hyp_enter reason=hvc [001] 323.847707: hyp_exit reason=eret_host [001] 323.847722: hyp_enter reason=hvc [001] 323.847723: hyp_exit reason=eret_host That's all fine as long as I'm dealing with a single guest, or even with a single vcpu. Trying to trace multiple guests, or even multiple vcpus makes the whole thing completely unusable, because I have no idea what I'm looking at. To make this useful, having some context provided by the host really is required.
I could add to the event header the VM pid related to the currently loaded vCPU (if any). I can access it easily with host_kvm->userspace_pid. WDYS?
Thanks, M. -- Without deviation from the norm, progress is not possible.