public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: oliver.upton@linux.dev, joey.gouly@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Re-allow hyp tracing HVCs for [nh]VHE
Date: Tue, 14 Apr 2026 15:58:04 +0100	[thread overview]
Message-ID: <ad5V_GuLY77xl8gw@google.com> (raw)
In-Reply-To: <86ik9t387m.wl-maz@kernel.org>

On Tue, Apr 14, 2026 at 03:52:29PM +0100, Marc Zyngier wrote:
> On Tue, 14 Apr 2026 11:02:31 +0100,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> > 
> > The introduction of __KVM_HOST_SMCCC_FUNC_MAX_NO_PKVM excluded hyp
> > tracing HVCs from the common [nh]VHE/pKVM list. Re-allow them.
> > 
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> > 
> > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> > index 37414440cee7..11dcdf434971 100644
> > --- a/arch/arm64/include/asm/kvm_asm.h
> > +++ b/arch/arm64/include/asm/kvm_asm.h
> > @@ -72,6 +72,14 @@ enum __kvm_host_smccc_func {
> >  	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
> >  	__KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
> >  	__KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
> > +	__KVM_HOST_SMCCC_FUNC___tracing_load,
> > +	__KVM_HOST_SMCCC_FUNC___tracing_unload,
> > +	__KVM_HOST_SMCCC_FUNC___tracing_enable,
> > +	__KVM_HOST_SMCCC_FUNC___tracing_swap_reader,
> > +	__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,
> >  	__KVM_HOST_SMCCC_FUNC___vgic_v3_save_aprs,
> >  	__KVM_HOST_SMCCC_FUNC___vgic_v3_restore_vmcr_aprs,
> >  	__KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr,
> > @@ -100,14 +108,6 @@ enum __kvm_host_smccc_func {
> >  	__KVM_HOST_SMCCC_FUNC___pkvm_vcpu_load,
> >  	__KVM_HOST_SMCCC_FUNC___pkvm_vcpu_put,
> >  	__KVM_HOST_SMCCC_FUNC___pkvm_tlb_flush_vmid,
> > -	__KVM_HOST_SMCCC_FUNC___tracing_load,
> > -	__KVM_HOST_SMCCC_FUNC___tracing_unload,
> > -	__KVM_HOST_SMCCC_FUNC___tracing_enable,
> > -	__KVM_HOST_SMCCC_FUNC___tracing_swap_reader,
> > -	__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/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 73f2e0221e70..8f7582d57ab5 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -709,6 +709,14 @@ static const hcall_t host_hcall[] = {
> >  	HANDLE_FUNC(__kvm_tlb_flush_vmid_range),
> >  	HANDLE_FUNC(__kvm_flush_cpu_context),
> >  	HANDLE_FUNC(__kvm_timer_set_cntvoff),
> > +	HANDLE_FUNC(__tracing_load),
> > +	HANDLE_FUNC(__tracing_unload),
> > +	HANDLE_FUNC(__tracing_enable),
> > +	HANDLE_FUNC(__tracing_swap_reader),
> > +	HANDLE_FUNC(__tracing_update_clock),
> > +	HANDLE_FUNC(__tracing_reset),
> > +	HANDLE_FUNC(__tracing_enable_event),
> > +	HANDLE_FUNC(__tracing_write_event),
> >  	HANDLE_FUNC(__vgic_v3_save_aprs),
> >  	HANDLE_FUNC(__vgic_v3_restore_vmcr_aprs),
> >  	HANDLE_FUNC(__vgic_v5_save_apr),
> > @@ -735,14 +743,6 @@ static const hcall_t host_hcall[] = {
> >  	HANDLE_FUNC(__pkvm_vcpu_load),
> >  	HANDLE_FUNC(__pkvm_vcpu_put),
> >  	HANDLE_FUNC(__pkvm_tlb_flush_vmid),
> > -	HANDLE_FUNC(__tracing_load),
> > -	HANDLE_FUNC(__tracing_unload),
> > -	HANDLE_FUNC(__tracing_enable),
> > -	HANDLE_FUNC(__tracing_swap_reader),
> > -	HANDLE_FUNC(__tracing_update_clock),
> > -	HANDLE_FUNC(__tracing_reset),
> > -	HANDLE_FUNC(__tracing_enable_event),
> > -	HANDLE_FUNC(__tracing_write_event),
> >  };
> 
> Why isn't it sufficient to reorder the enum?
> 
> Thanks,
> 
> 	M.

It is, I just thought we might want to keep both in the same order. WDYS?

> 
> -- 
> Without deviation from the norm, progress is not possible.


  reply	other threads:[~2026-04-14 14:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 10:02 [PATCH] KVM: arm64: Re-allow hyp tracing HVCs for [nh]VHE Vincent Donnefort
2026-04-14 14:52 ` Marc Zyngier
2026-04-14 14:58   ` Vincent Donnefort [this message]
2026-04-17 14:23 ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad5V_GuLY77xl8gw@google.com \
    --to=vdonnefort@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox