[RFC PATCH v2 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
Marc Zyngier
maz at kernel.org
Thu Apr 23 08:34:46 UTC 2026
On Wed, 22 Apr 2026 17:24:49 +0100,
Yeoreum Yun <yeoreum.yun at arm.com> 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 <yeoreum.yun at arm.com>
> ---
> 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.
More information about the Linux-security-module-archive
mailing list