On Wed, Oct 3, 2018 at 3:31 PM, Jorge Ramirez-Ortiz jramirez@baylibre.com wrote:
On 10/03/2018 03:17 PM, Jens Wiklander wrote:
On Wed, Oct 3, 2018 at 2:27 PM, Jorge Ramirez-Ortiz jramirez@baylibre.com wrote:
I am upstreaming TF-A support for the Renesas R-car gen3 platforms [1].
In order to prevent the boot cpu from being switched off (hotpluged) I am having to work around the fact that OPTEE_OS does not support MIGRATE_INFO_TYPE or MIGRATE_INFO_UP_CPU.
Why should OP-TEE care about that?
the boot cpu boots OP-TEE; when OP-TEE has migration requirements the boot cpu must not be hot-plugged.
This sounds a bit odd, what in OP-TEE makes the boot cpu so special?
Isn't it rather the SoC that has this requirement? If so perhaps this restriction belongs in the PCSI implementation instead?
So OP-TEE in away should care about implementing those interfaces (unless every OP-TEE ever created is guaranteed to have no migration restrictions).
Trying to predict what every fork of OP-TEE will ever do is not easy so I'm sticking to upstream OP-TEE.
Its SPD at TF-A level [2] returns that the TrustedOS if fully MP aware and has not special requirements for migration.
Isn't that true for upstream OP-TEE?
? but what happens if the user is working with a non-upstream OP-TEE? The way TF-A has been written hard-codes the requirement of an OP-TEE with no migration restrictions.
We try to not make it harder that necessary for the forks, but if there's a conflicts of interests it's upstream that matters.
IMO the code at this level should be generic and always query. why dont you see it this way?
So far I'm not convinced that it's needed, but I'll try to keep an open mind.
The work around I implemented (patch below and [3]) will query the platform whenever the opteed SPD indicates that it has no migration restrictions (which currently is always)
Is there any work ongoing on OPTEE_OS to support MIGRATE_INFO and update the TF-A SPD or am I missing some fundamental point?
No, there's no work ongoing in this area. Please elaborate on why this is needed.
see the above comments (should I elaborate more? not sure what else to add :))
Yes, I'd like to know why this isn't done in the PSCI implementation in TF-A.
Thanks, Jens