Hi Varun,
The issues faced below are not design issues, but the effect of re-purposing a component to a new goal. You can obviously submit patches, although I think those changes will have to be conditioned by a "CACTUS_SEL1_SPMC" define which can be perfectly fair. See more answers inline [OD].
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 01 September 2020 06:30 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org Subject: List of issues with Cactus as SPMC on pre-8.4 CPUs
Hi @Oliviermailto:Olivier.Deprez@arm.com,
We have been trying to use Cactus as SPMC on Tegra194 (pre 8.4) platforms and have faced the following issues.
1. Cactus_main.c – During cold boot, Cactus checks if the ffa-id for the instance of Cactus == SPM_VM_ID_FIRST. It issues FFA_ID_GET SMC to TF-A which returns the spmc_id in return. But on pre-8.4 platforms the value does not match SPM_VM_ID_FIRST and so the system assumes that the device is running on a post-8.4 CPU. The problem is that TF-A returns the spmc_id for this SMC, which seems incorrect. I don’t understand why Cactus needs to know its own VM_ID on pre-8.4 CPUs. Can we assume that only one SPMC can run on pre-8.4?
[OD] Generally an FF-A endpoint needs to know its own ID e.g. to properly provide a source endpoint id in a direct message request/response. The SPMC can gather its own id at secure physical FF-A instance (from the SPMD) which is what you get here (see https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti...). Similarly, an SP can get its ID at secure virtual FF-A instance (returned by the SPMC) which is what Cactus is currently designed for. In any case, yes on pre-v8.4 systems you're likely to only have one combined SP+SPMC instance.
2. Cactus_ffa_tests.c – The ` ffa_partition_info_get_test` incorrectly queries the partition info for secondary and tertiary VMs on pre-8.4 CPUs.
[OD] Querying partition info get from the SPMC to the SPMD is an invalid scenario like you get in this case. The valid use case is Cactus (S-EL1) querying partition info get to the SPMC (S-EL2). Or similarly in the Nwd, partition info get from a VM to the Hypervisor, or the Hypervisor to the SPMC.
3. In general the boot tests that execute within Cactus seem incorrect to me. Some tests expect the presence of a non-secure world payload, which is not available at this point in the boot. This leads to numerous crashes and asserts during boot.
[OD] When Cactus runs at secure virtual FF-A instance, all boot test cases are run in the Cactus+SPMC boundary in the SWd. There is no assumption on the NWd at this stage. What you observe is the effect of running this same code at secure physical FF-A instance.
4. Cactus incorrectly uses a hard-coded address 0x7300000 as the RX/TX memory base. It should be using a platform defined value instead. We do not support this memory address on Tegra194.
[OD] That's a fair point indeed. All developments/validations were made so far by using the FVP. I had few discussions internally around this, I can get back to you.
5. The debug UART in Cactus needs rework too. Right now, it only supports PL011 as the UART driver.
[OD] Right, same comment as above.
6. TF-A SPMD forwards some SMCs to the non-secure world without checking if a non-secure world payload exists. This causes crashes during cold boot.
[OD] I think again that's an effect of running cactus code at physical FF-A instance which is not what it was designed for.
Please let me know if you have commits for any or all of these issues. We have some WIP commits that we can push to gerrit for review, if required.
Thoughts?
-Varun