[Cherry-Pick][Rebase & FF] Adding FF-A support from EDK2 #1261
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
os-d
approved these changes
Jan 24, 2025
github-actions
bot
added
the
impact:breaking-change
yep, these mu_change interventions should be gone once the edk2 change is pushed through. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev/202405 #1261 +/- ##
===========================================
Coverage 1.60% 1.60%
===========================================
Files 1379 1379
Lines 359694 359694
Branches 5524 5524
===========================================
Hits 5760 5760
Misses 353827 353827
Partials 107 107
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
kuqin12
force-pushed
the
ffa_enablement_4_edk2
branch
2 times, most recently
from
24c17fa to
95e4cd3
Compare
cfernald
approved these changes
Jan 24, 2025
makubacki
approved these changes
Jan 24, 2025
kuqin12
force-pushed
the
ffa_enablement_4_edk2
branch
from
95e4cd3 to
c98d877
Compare
This patch introduces a PI_MM_CPU_DRIVER_EP protocol to handle
Mmcommunication request based on the CPU driver.
Previously the CPU driver entry point was retrieved using the
gEfiArmTfCpuDriverEntryPoint HOB.
However, this practice is incorrect as StandaloneMM must be a HOB
consumer and not a HOB producer.
Therefore, remove the CPU entry HOB gEfiArmTfCpuDriverEntryPoint,
and replace it with the CPU driver entry protocol
EDKII_PI_MM_CPU_DRIVER_EP_PROTOCOL.
The EDKII_PI_MM_CPU_DRIVER_EP_PROTOCOL installed in
StandaloneMmCpuInitialize() will be used by the code in
Arm/StandaloneMmCoreEntryPoint.
This protocol is used like below:
+=====+
|StandaloneMmCore|
+=====+
|
CEntryPoint()
===================
|
ProcessModuleEntryPointList()
|
+--> StandaloneMmMain()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| // Load StandaloneMmCpu driver which implements
| // CpuDriverEntryPoint used by DelegatedEventLoop().
| // and install the gEdkiiPiMmCpuDriverEpProtocolGuid.
--------------
|
... // Get CpuDriverEntryPoint implemented by
// StandaloneMmCpu driver with gEdkiiPiMmCpuDriverEpProtocolGuid
|
DelegatedEventLoop() // Handle request by delegating it to
// CpuDriverEntryPoint.
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
(cherry picked from commit 6087382c62686130a6cb8bd397afe23bad9c4e67)
By using transfer list passed by TF-A, StandaloneMmCore is no more producer of HOBs, But it is consumer. So, the Arm-specific implementation of StandaloneMmCoreHobLib is no longer needed. This change removes the Arm-specific HOB creation code and integrates the necessary adjustments. Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit 31fcaf1fc0dba3bc6494ef3e6acac78ee9c795b1)
To remove hob creation in StandaloneMm entrypoint, TF-A should pass PHIT hob information to StandaloneMm. When it passes PHIT hob, it passes according to firmware handoff specification[0]. This patch applies boot protocol using transfer list with firmware handoff specification and remove hob creation in StandaloneMm entrypoint. Link: https://github.com/FirmwareHandoff/firmware_handoff [0] Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit a5212d3db79312f65f0392f294e43193c148199f)
To support the service other than Mmcommunication service,
StandaloneMm should use FF-A v1.2 or later [0].
For this, StandaloneMm needs to change:
1. apply FF-A boot protocol
- FF-A uses its own boot protocol and it can deliver phit hob.
So, StandaloneMm should understand FF-A boot protocol and
get phit hob from it to initialize.
2. Use DIRECT_REQ2 / DIRECT_RESP2
- To support the other service via FF-A protocol
than MmCommunication,
StandaloneMm should use DIRECT_REQ2 / DIRECT_RESP2.
In case of service provided with MmCommunication protocol,
register x2/x3 value is set as gEfiMmCommunication2ProtocolGuid and
register x4 value is set with MmCommunication Buffer
(ServiceTypeMmCommunication).
In case of service with each speicifiation via FF-A,
register x2/x3 value is set as each service guid
and StandaloneMmCoreEntryPoint genreates Mm communication header
with passed arguments to dispatch this service
provided by StandaloneMm.
i.e) Tpm service, Firmware update service and etc.
(ServiceTypeMisc)
Link: https://developer.arm.com/documentation/den0077/latest/ [0]
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
(cherry picked from commit 1c963008e8d7ec8b676478ab42ff40b41cb32be0)
On Arm all requests are handled as Asynchronous events by the Root MMI handler. Since the communication data is conveyed using either the NS shared buffer or the Secure shared buffer, the Arm implementation does not setup the mCommunicationBuffer. Therefore, the mCommunicationBuffer being NULL is not an error case. Moreover, the existing code switches to Asynchronous event processing when the mCommunicationBuffer is NULL, which means that the log is an info log rather than an error. Therefore, change the log level from ERROR to INFO when the mCommunicationBuffer is NULL. Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit 6016c522c6d6e7d6cce385379cfbe8f06cf8048e)
There are 2 communication interfaces between the SPMC and StandaloneMM 1. SpmMM 2. FF-A When SpmMM is enabled, TF-A acts as the SPMC at EL3 and the stack is setup by TF-A for use by StandaloneMm. However, when FF-A is enabled, the SPMC does not setup the stack for StandaloneMm and it is expected that the StandaloneMm code will setup its own stack. Therefore, reserve an area in the data region for use as the stack for StandaloneMM. This stack will be used in both the scenarios described above, i.e. when either SpmMM or FF-A is enabled. Although the stack is reserved from the data section which is expected to be Read-Write enabled, when TF-A maps the StandaloneMM binary into the DRAM it configures the entire StandaloneMM memory as Read-Only. Therefore, before the stack can be utilised, the PE Coff sections need to be scanned to change the the stack region from Read-Only to Read-Write. Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit 7340a4b63a993151817faa0adabebfeb007d16c1)
Arm has three types of communication buffer
- Non secure communication buffer: shared buffer with NS partition
- Secure communication buffer: shared buffer with Secure partition
- Internal Misc service buffer: For misc service
i.e. for services that do not use MmCommunication protocol,
a buffer is created and populated internally.
Since, internal Misc service buffer is allocated dynamically in
StandaloneMm there is no additional check required for the Misc
service buffer.
This patch move sanity check of communication buffer from
StandaloneMmCpu Driver to StandaloneMmEntryPoint.
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
(cherry picked from commit 6c62f40df3f63732071dc97f23830b2e48c6cbc5)
The default ExtractGuidedSectionLib used by Standalone MM is the implementation in EmbeddedPkg. However, the ExtractGuidedSectionLib implementation in EmbeddedPkg builds HOBs to save the extract handler information. Since StandaloneMm is consumer of HOB, not a HOB producer, introduce a StandaloneMmExtraGuidedSectionLib implementation that saves the extract handler information in the ConfigurationTable. This StandaloneMmExtraGuidedSectionLib can be used by MM_STANDALONE and MM_CORE_STANDALONE modules. Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit b370eab8987d27fe9b679201d85312b06ac3b730)
StandaloneMmCpu driver is only used for Arm architecture and StandaloneMmCoreEntryPointLib for Arm has specific implementation with StandaloneMmCpu driver. Move StandaloneMmCpu Driver and StandaloneMmCoreEntryPointLib for Arm to ArmPkg. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Levi Yun <yeoreum.yun@arm.com> (cherry picked from commit f0c87b9ef421954ec0e7942d9e8d7d4d14b208b3)
kuqin12
force-pushed
the
ffa_enablement_4_edk2
branch
from
c98d877 to
3f44d3e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change cherry-picks the commits applicable to basecore from edk2 FF-A support PR.
How This Was Tested
This change was tested on a QEMU SBSA platform with Hafnium as SPMC configuration.
Integration Instructions
Marking it as a breaking change because no more hob creation will be allowed from stmm after this change.