Re: [RFC PATCH v2 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver

On Wed, 22 Apr 2026 17:24:49 +0100,
Yeoreum Yun <[email protected]> wrote:
> 
> When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> Otherwise, pKVM cannot negotiate the FF-A version or
> obtain RX/TX buffer information, leading to failures in FF-A calls.
> 
> During FF-A driver initialization, check whether pKVM has been initialized.
> If pKVM isn't initailised, register notifier and do initialisation
> of FF-A driver when pKVM is initialized.
> 
> Signed-off-by: Yeoreum Yun <[email protected]>
> ---
>  arch/arm64/include/asm/virt.h     | 11 ++++++++++
>  arch/arm64/kvm/arm.c              | 21 ++++++++++++++++++
>  arch/arm64/kvm/pkvm.c             |  2 ++
>  drivers/firmware/arm_ffa/common.h |  4 ++--
>  drivers/firmware/arm_ffa/driver.c | 36 ++++++++++++++++++++++++++++++-
>  drivers/firmware/arm_ffa/smccc.c  |  2 +-
>  6 files changed, 72 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index b51ab6840f9c..ad038a3b8727 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -68,6 +68,8 @@
>  #include <asm/sysreg.h>
>  #include <asm/cpufeature.h>
> 
> +struct notifier_block;
> +
>  /*
>   * __boot_cpu_mode records what mode CPUs were booted in.
>   * A correctly-implemented bootloader must start all CPUs in the same mode:
> @@ -166,6 +168,15 @@ static inline bool is_hyp_nvhe(void)
>  	return is_hyp_mode_available() && !is_kernel_in_hyp_mode();
>  }
> 
> +enum kvm_arm_event {
> +	PKVM_INITIALISED,
> +	KVM_ARM_EVENT_MAX,
> +};

Well, no.

You are adding a whole infrastructure for something that happens
*once* in the lifetime of the system. What's next? D-Bus?

We already have a dependency mechanism, which I pointed to you last
time, and that you conveniently ignored. If that's not working for
you, then consider improving it.

If we had a whole set of in-kernel users depending on some global KVM
state change, we could look into it. But they are none, and all KVM
state changes are per-vcpu rather global.

So I'm not entertaining this invasive infrastructure for something so
limited.

	M.

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