Hi,
I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.trusted...) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add).
Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 .
Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API).
I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch.
I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well?
Hi Julius,
I see your request as two-fold 1. Having a range for TF-A specific SMC's : Currently we are having internal discussion whether we need a range for this and where exactly it should be (probably a sub-range in std services). Personally i think it's a genuine request, in fact there are few existing functionalities which qualify to be part of this range (PMF/DebugFS) but they are kept as part of Arm SiP. 2. SMC to get CBMEM console address: As you mentioned that it is required only once and not-necessarily a runtime use case. Is it possible to implement this using Firmware Handoff mechanism? Considering the specification is almost at final stage and TF-A implementation is likely to happen in not-so-distant future.
Thanks Manish ________________________________ From: Julius Werner via TF-A tf-a@lists.trustedfirmware.org Sent: 11 April 2023 23:02 To: tf-a tf-a@lists.trustedfirmware.org Cc: Dan Handley Dan.Handley@arm.com; Soby Mathew Soby.Mathew@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com; Jeffrey Kardatzke jkardatzke@google.com; Sandeep Tripathy sandeep.tripathy@broadcom.com Subject: [TF-A] Need a mechanism to easily define platform-independent SMC FIDs
Hi,
I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.trusted...) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add).
Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 .
Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API).
I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch.
I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well? -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
- Having a range for TF-A specific SMC's : Currently we are having internal discussion whether we need a range for this and where exactly it should be (probably a sub-range in std services). Personally i think it's a genuine request, in fact there are few existing functionalities which qualify to be part of this range (PMF/DebugFS) but they are kept as part of Arm SiP.
Yes, a sub-range of "standard" would also work. My main concern is that it should be easy and low-friction for developers (especially non-Arm contributors like us who aren't that well-networked to the teams owning the specs) to add new FIDs there -- e.g. it should just take a Gerrit CL or Github PR that can be reviewed in a week or two, not a new revision of the whole SMCCC spec that needs to go through a dozen committees or however that works.
- SMC to get CBMEM console address: As you mentioned that it is required only once and not-necessarily a runtime use case. Is it possible to implement this using Firmware Handoff mechanism? Considering the specification is almost at final stage and TF-A implementation is likely to happen in not-so-distant future.
Yes, true, it's possible an SMC wasn't the right solution for this in the first place. Let's continue to discuss that on Gerrit. But even if we don't end up needing an SMC for this one there's still a general need to define generic SMCs like that every once in a while for other things.
Hi Julius / All,
We are adding Vendor specific EL3 subrange which is part of SMCCC-1.5 updates to TF-A and moving DebugFS and PMF to this subrange. The patches are in review in here: https://review.trustedfirmware.org/q/project:TF-A/trusted-firmware-a+topic:%...
--
Thanks,
Govindraj R
________________________________ From: Julius Werner via TF-A tf-a@lists.trustedfirmware.org Sent: Friday, April 14, 2023 18:17 To: Manish Pandey2 Manish.Pandey2@arm.com Cc: tf-a tf-a@lists.trustedfirmware.org; Dan Handley Dan.Handley@arm.com; Soby Mathew Soby.Mathew@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com; Jeffrey Kardatzke jkardatzke@google.com; Sandeep Tripathy sandeep.tripathy@broadcom.com Subject: [TF-A] Re: Need a mechanism to easily define platform-independent SMC FIDs
- Having a range for TF-A specific SMC's : Currently we are having internal discussion whether we need a range for this and where exactly it should be (probably a sub-range in std services). Personally i think it's a genuine request, in fact there are few existing functionalities which qualify to be part of this range (PMF/DebugFS) but they are kept as part of Arm SiP.
Yes, a sub-range of "standard" would also work. My main concern is that it should be easy and low-friction for developers (especially non-Arm contributors like us who aren't that well-networked to the teams owning the specs) to add new FIDs there -- e.g. it should just take a Gerrit CL or Github PR that can be reviewed in a week or two, not a new revision of the whole SMCCC spec that needs to go through a dozen committees or however that works.
- SMC to get CBMEM console address: As you mentioned that it is required only once and not-necessarily a runtime use case. Is it possible to implement this using Firmware Handoff mechanism? Considering the specification is almost at final stage and TF-A implementation is likely to happen in not-so-distant future.
Yes, true, it's possible an SMC wasn't the right solution for this in the first place. Let's continue to discuss that on Gerrit. But even if we don't end up needing an SMC for this one there's still a general need to define generic SMCs like that every once in a while for other things. -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
tf-a@lists.trustedfirmware.org
-
Govindraj Raja -
Julius Werner -
Manish Pandey2