Re: [PATCH v4 5/5] xen/arm: ffa: Enable VM to VM without firmware

[Julien Grall <julien@xxxxxxx>]

Hi Bertrand,

On 27/03/2025 08:37, Bertrand Marquis wrote:
> > On 27 Mar 2025, at 00:41, Julien Grall <julien@xxxxxxx> wrote:
> >
> > Hi Bertrand,
> >
> > On 24/03/2025 13:53, Bertrand Marquis wrote:
> > > When VM to VM support is activated and there is no suitable FF-A support
> > > in the firmware, enable FF-A support for VMs to allow using it for VM to
> > > VM communications.
> > tee/ and the callbacks associated are meant to be used for mediatiors. My current 
> > interpretation ist this is only meant to interpose between a guest and physical 
> > resources. Here you are extending the meaning to "virtual TEE". I am sort of ok 
> > with that but ...
> I see what you mean but FF-A will not only be used to communicate with TEE 
> (even if the primary use case right now is this one, including have it in a VM 
> instead of the secure world).
> >>
> > > If there is OP-TEE running in the secure world and using the non FF-A
> > > communication system, having CONFIG_FFA_VM_TO_VM could be non functional
> > > (if optee is probed first) or OP-TEE could be non functional (if FF-A is
> > > probed first) so it is not recommended to activate the configuration
> > > option for such systems.
> > ... this part is concerning me. You should be able to build with 
> > CONFIG_FFA_VM_TO_VM and still boot when OP-TEE is present on the system. This 
> > is not too critical now as this is tech preview but this is definitely a 
> > blocker for making FFA supported. Can this be mentioned at the top of the ffa.c 
> > file (which already contains existing blocker)?
> OP-TEE supports FF-A and in fact should be switched to using it by default as 
> it allows it to run in parallel of other TEEs in the secure world or have FF-A 
> compliant SPs running on top of OP-TEE.
> More and more you will see FF-A popping up as a recommended (or required) part 
> of the firmware features.
>
> So the only reason to use OP-TEE without FF-A is if you have an old OP-TEE in 
> which case your firmware will not support FF-A and using it between VMs is 
> probably not required.
Thanks for the clarification. I know we only support OP-TEE in Xen 
today, but do you know what will happen for the other TEEs? Will they 
adopt FF-A?
> > Also, given this would expose a fully virtual TEE, we should be able to have a 
> > system where you have some VMs talking FFA and some using the physical OPTEE 
> > (or another TEE). Whether we want to support it is a different question but 
> > this design would prevent it. Is this intended?
> Right now i would say this is definitely not something we need as part of the 
> tech preview as anybody using this feature in Xen would use an OP-TEE with FF-A 
> support.
> But from Xen point of view, we should (if we can) support running on old 
> systems with an existing OP-TEE but still use FF-A between VMs.
> This has some consequences on how the tee mediator and FF-A support is designed 
> and I will definitely give it some thoughts (primary idea would be to decouple 
> FF-A with secure as mediator to FF-A between VMs somehow).
I am not sure we need to decouple anything. Today, we can already 
specify the type of the TEE used by a given VM (see tee_type). But we 
are enforcing the TEE type match the one of the current mediator.
So what if we allow multiple mediator to run and when the domain is 
initialized we select the correct medatior/ops for the VM?
For simplification, we could even hardocode FF-A as the second mediator.

> For the review side of things, am I right to understand from your comments that 
> this ok for now as tech-preview ?
Yes I am happy with the approach for now.

Cheers,

--
Julien Grall