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 <jul...@xen.org> wrote: > > > > On 23/09/2024 13:27, Jens Wiklander wrote: >> Hi, > > Hi, > >> On Sun, Sep 22, 2024 at 3:04 PM Julien Grall <jul...@xen.org> 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
