On Mon, Apr 20, 2026 at 02:20:35PM +0000, Sebastian Ene wrote: > On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote: > > On Mon, 20 Apr 2026 13:32:32 +0100, > > Sebastian Ene <[email protected]> wrote: > > > > > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote: > > > > > > Hello Yeoreum, > > > > > > > > > > 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. > > > > > > At the moment this already happens after you move back ffa_init() to > > > device_initcall(). > > > > But relying on this sort of ordering is just making things more > > fragile. > > > > Thanks for letting me know. Since this is not a solid construct we will have > to change the driver init code to come after pKVM in this case. > > > > > > > > > > > > During FF-A driver initialization, check whether pKVM has been > > > > initialized. > > > > If not, defer probing of the FF-A driver. > > > > > > > > > > I don't think you need to add this dependency. pKVM is > > > installed through KVM's module_init() which ends up calling > > > hyp_ffa_init() to > > > do the proxy initialization. The ARM-FFA driver comes after it (since > > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to > > > be able to handle smc(FF-A) calls in the hyp-proxy. > > > > You do. Without the finalisation, SMCs are not trapped by EL2. > > > > And even if it did, relying on such hack is just wrong. > > > > That makes it an even stronger argument to move the driver init at a > later stage. I was relying on this to trap early ff-a when the > ARM FF-A driver was used.
I don’t think moving the FF-A driver initialization to a later stage is a viable solution. For example, even if it is moved to device_initcall_sync, it still relies on fragile ordering. Similarly, moving it to late_initcall is problematic. Since deferred_probe_initcall() runs at the same level, if it is invoked first, devices that depend on FF-A (e.g. tpm_ffa_crb) may not be probed correctly, leading to deferred devices not being handled properly. Therefore, the FF-A driver should be able to detect when pKVM has been initialized and perform its initialization accordingly otherwise, just relying on the trap after kvm_arm_initialised. -- Sincerely, Yeoreum Yun
