[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