search

ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

opteed_cpu_migrate_info #617

Open ldts opened 6 years ago

ldts commented 6 years ago

shouldnt opteed_cpu_migrate_info be able to reach the platform specific code instead of returning OPTEE_MIGRATE_INFO?

soby-mathew commented 6 years ago

Hi @ldts, Whether the Trusted OS is MP or UP/UP migratable is something that the platform is usually not able to influence and is built into the Trusted OS design. Hence that could be reason why the call terminates at the optee generic code level and not percolated to the platform level.

ldts commented 6 years ago

@soby-mathew sorry I think I didnt explain myself properly. let me put it differently, shouldn't the common code ask the platform about its TEE capabilities instead of assuming what it can do?

soby-mathew commented 6 years ago

The terminology maybe causing some confusion here I think. Opteed is the dispatcher component of optee and it is maintained by the optee folks. The opteed_cpu_migrate_info is part of Opteed, and hence is aware of the optee capability.

I am not sure of internals of optee, but maybe it doesn't allow platforms to change the cpu migrate behaviour. Anyway, this is a question more appropriate for optee maintainers to answer.

ldts commented 6 years ago

right, but what I mean is that before the dispatcher calls optee, the platform might want to take some actions. Currently there is no provision for that (opteed has no interface to the platform). my question is, why not? these actions might be sensitive to the order of the calls hence trying to push them via plat_psci_ops_t is probably not the best option. what would be the right forum to discuss? Shall I ping Joakim?

soby-mathew commented 6 years ago

I see what you mean. You need an additional hook to the platform layer from the dispatcher before the plat_psci_ops_t hook is invoked. Yes, this would need discussion with @jenswi-linaro and @jbech-linaro.