summaryrefslogtreecommitdiff
path: root/BaseTools/Source/Python/Workspace/BuildClassObject.py
diff options
context:
space:
mode:
authorYeoreum Yun <yeoreum.yun@arm.com>2026-09-04 16:26:00 +0300
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2026-09-30 06:44:56 +0300
commitb5aea432d486ce457a77304882225b41f0aebe73 (patch)
tree008d14e0c13b1220ad267bdf9adb055e79115c67 /BaseTools/Source/Python/Workspace/BuildClassObject.py
parent1e550744fdf02d897ef5f37c6963675da7d732e4 (diff)
downloadedk2-b5aea432d486ce457a77304882225b41f0aebe73.tar.xz
ArmPkg/Library: remove FFA_ERROR() return for FFA_SEND_DIRECT_MSG_REQ(v2)
There is a known issue [0] where the SPMC repeatedly re-enters Standalone MM with FFA_ERROR after Standalone MM returns FFA_ERROR because it failed to locate an MMI handler for an MM communication request. Although the FF-A specification does not currently clarify this behavior, it is expected to be updated. Once Standalone MM is entered through FFA_MSG_SEND_DIRECT_REQ or FFA_MSG_SEND_DIRECT_REQ2, it must return through FFA_MSG_SEND_DIRECT_RESP or FFA_MSG_SEND_DIRECT_RESP2, respectively. Therefore, do not return FFA_ERROR after Standalone MM has been entered through a direct request. Standalone MM handles two types of services received through direct requests: ServiceTypeMmCommunication and ServiceTypeMisc. For ServiceTypeMmCommunication, protocol errors are returned through the communication buffer, so the handler itself should return EFI_SUCCESS. However, failures may occur outside the handler, such as when no matching MMI handler can be found. In these cases, construct the direct response as follows: - FFA_MSG_SEND_DIRECT_RESP: x0 = ARM_FID_FFA_MSG_SEND_DIRECT_RESP x1 = Source/destination partition IDs x2 = 0x00 x3 = ARM_FID_SPM_MM_SP_EVENT_COMPLETE x4 = ARM_SPM_MM_RET_* - FFA_MSG_SEND_DIRECT_RESP2: x0 = ARM_FID_FFA_MSG_SEND_DIRECT_RESP2 x1 = Source/destination partition IDs x2 = 0x00 (SBZ) x3 = 0x00 (SBZ) x4 = ARM_FID_SPM_MM_SP_EVENT_COMPLETE x5 = ARM_SPM_MM_RET_* Although this convention is not formally documented, it has been used since edk2 commit 388dfe02fb9a ("StandaloneMmPkg: Add option to use..."). For ServiceTypeMisc, the handler returns the complete response, including any protocol-specific error code and arguments, directly through FfaArgs. The handler is therefore responsible for constructing FfaArgs and should return EFI_SUCCESS. All ServiceTypeMisc handlers are registered during Standalone MM initialization, and initialization fails if any handler cannot be registered. A failure returned by a ServiceTypeMisc handler is therefore unexpected. There is no generic way to construct FfaArgs for a direct response in this situation. Call CpuDeadLoop() instead of returning an invalid response. Closes: https://github.com/tianocore/edk2/issues/12646#issuecomment-5523596676 [0] Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Diffstat (limited to 'BaseTools/Source/Python/Workspace/BuildClassObject.py')
0 files changed, 0 insertions, 0 deletions