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"?
Cheers,
--
Julien Grall
