[PATCH v1 3/3] KVM: arm64: Add host_hvc hyp event
Fuad Tabba
fuad.tabba at linux.dev
Fri Oct 9 05:26:22 PDT 2026
Hi Vincent,
On Fri, 09 Oct 2026 09:45:29 +0100, Vincent Donnefort
<vdonnefort at google.com> wrote:
[...]
> diff --git a/arch/arm64/include/asm/kvm_hypevents.h b/arch/arm64/include/asm/kvm_hypevents.h
[...]
> +HYP_EVENT(host_hvc,
> + HE_PROTO(u8 id, u64 ret),
> + HE_STRUCT(
> + he_field(u8, id)
> + he_field(u64, ret)
> + ),
> + HE_ASSIGN(
> + __entry->id = id;
> + __entry->ret = ret;
> + ),
> + HE_PRINTK("id=%u ret=0x%llx", __entry->id, __entry->ret)
> +);
id is the index into host_hcall[], so its value depends on that
table's order. Could this log the SMCCC function ID instead, as
guest_hvc does? The alignment issue from patch 2 applies here too: the
format file puts ret at offset 3 instead of 8.
[...]
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
[...]
> @@ -996,6 +996,8 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
> cpu_reg(host_ctxt, 0) = SMCCC_RET_SUCCESS;
> hfn(host_ctxt);
>
> + trace_host_hvc(id, cpu_reg(host_ctxt, 1));
> +
> return;
> inval:
> cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
Only some of the handlers write a return value to x1. For the others,
x1 still holds the first argument, e.g. the mmu pointer for
__kvm_tlb_flush_vmid, so host_hvc's ret field shows that instead.
Could the field be called x1 rather than ret?
Cheers,
/fuad
More information about the linux-arm-kernel
mailing list