Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Yeoreum Yun <yeoreum.yun@arm.com>]

Hi,

> On Tue, May 05, 2026 at 05:58:32PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> > 
> > > On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > > > Hi Sudeep,
> > > > 
> > > > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > > > buffer information, leading to failures in FF-A calls.
> > > > > > 
> > > > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > > > while ffa_init() runs at the device_initcall level.
> > > > > > 
> > > > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > > > still be trapped even before finalise_pkvm() is invoked.
> > > > > > As a result, this issue has not been observed.
> > > > > > 
> > > > > > However, relying on above stuff is fragile.
> > > > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > > > initialised only after pKVM initialisation has been fully finalised.
> > > > > > 
> > > > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > > > when pKVM is enabled.
> > > > > > 
> > > > > 
> > > > > I don't like this whole ffa root device design.
> > > > > Two question for now:
> > > > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > > >    this dance done here ?
> > > > 
> > > > But this means we reduce the other feature e.x) IMA with TPM over
> > > > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > > > to build FF-A driver with built-in.
> > > > 
> > > > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > > >    and defer it instead of this root ffa device.
> > > > 
> > > > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > > > FF-A initialisation is finished and How can we trigger FF-A initailise
> > > > after pKVM finish its initialisation?
> > > > 
> > > > The problem is ff-a intiailisation happens before pKVM finish its
> > > > initailasation and to do defer probe, it should use dd-model and
> > > > As we discussed in other thread, notifier couldn't be a soluation.
> > > > 
> > > > Could you let me share other way I'm missing?
> > > > 
> > > 
> > > Will something like below work ?
> > 
> > It might work and when I write the code I thougt about whether to
> > use add platform device but I didn't find why this is better than
> > to create root device of FF-A (anyway creating a simple platform device
> > for FF-A seems similar to create root device)
> 
> First, you tried to force the FF-A core to be treated as an FF-A device, then
> added several bus-code changes to handle it as a "special root" device while
> skipping all FF-A device functionality. Please consider the purpose of
> creating it as an FF-A device if additional code is then required to bypass
> the functionality it provides.

Okay. I'll do with platform device then.

> 
> > If you don't mind why it would be better than to create FF-A root
> > device in FF-A bus?
> > 
> > > If we add DT bindings, then we can add
> > > of_match_table and drop the platform device creation. Also we can adjust
> > > the parent device the way you have done by a simple change(not done in
> > > this untested/not compiled change).
> > 
> > Might for a DT, but do we need to platform device creation for ACPI case
> > anyway?
> > 
> >
> 
> Just acpi_match_table instead of of_match_table.

I mean like DT node, it seems to add some "FF-A" device for this.
Anyway, right now as your suggestion, let me respin with platform device
again.

-- 
Sincerely,
Yeoreum Yun