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. > M. > > -- > Without deviation from the norm, progress is not possible. Thanks, Sebastian
