Re: [PATCH 04/10] xen/arm: ffa: Fine granular call support

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

I will answer after to your previous comments but I wanted to jump in on this 
subject first.

> On 25 Sep 2024, at 18:56, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 23/09/2024 13:27, Jens Wiklander wrote:
>> Hi,
> 
> Hi,
> 
>> On Sun, Sep 22, 2024 at 3:04 PM Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On 19/09/2024 14:19, Bertrand Marquis wrote:
>>>> Create a bitmap to store which feature is supported or not by the
>>>> firmware and use it to filter which calls done to the firmware.
>>>> 
>>>> With this enabled. allow FF-A support to be activated for guest even if
>>> 
>>> Typo: s/./,/ I think.
>>> 
>>>> the firmware does not support it.
>>> 
>>> Can you explain why you want to do this?
>>> 
>>> The TEE mediator was designed to interpose with the HW. Without the HW
>>> it doesn't entirely make sense to try to use it.
>>> 
>>> It would also not work if the host system is using OP-TEE and expose to
>>> some VM FF-A. So it feels that the mediator may not be the right place
>>> to handle this case.
>> That's a good point, but all the FF-A handling should be in the same
>> module since there's bound to be code and state to share. The problem
>> is that FF-A tries to be a TEE mediator while it's about to become
>> more than that. We can work around it by probing the OP-TEE mediator
>> first, but it's adding another exception or special case. Would it
>> make sense to move the FF-A mediator out of the TEE mediator framework
>> and establish it separately?
> 
> I don't particularly want to have the FF-A mediator out of the TEE mediator. 
> At the moment, it is unclear to me how much of the SMC handling code can 
> really be shared between a domain talking with the host firmware and an 
> emulated version. Are we just going to end up to have "if firmware then to 
> this else do that"?

We will need to have a debate on how to handle Optee Mediator versus FF-A once 
we have FF-A support between VM.
In this case we could have cases where the firmware and secure world does not 
support FF-A and optee is using the current protocol but someone wants to use 
FF-A between VMs. My guts feeling right now is that we could (and probably 
should) not allow this use case as it would be realistic to say that a firmware 
support FF-A at some point would not support the old optee protocol.

At the status of this patch (and i do not plan to push VM to VM support in 
anything else than an RFC in the next weeks), I think FF-A should stay as a TEE 
mediator and I will revert the change enabling FF-A support in Xen when the 
firmware does not support it as we do not need that before VM to VM FF-A 
support is added.

Now even with that comes a question: What to do if the firmware supports FF-A 
but secure world has optee but using the old protocol.
Should we probe optee first and FF-A second ?

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall