Skip to content

ArmPkg: Handle FFA_BUSY response for MM communication#1825

Merged
cfernald merged 1 commit into
microsoft:release/202511from
cfernald:ffa_busy_fix
Jun 22, 2026
Merged

ArmPkg: Handle FFA_BUSY response for MM communication#1825
cfernald merged 1 commit into
microsoft:release/202511from
cfernald:ffa_busy_fix

Conversation

@cfernald

@cfernald cfernald commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Description

MM communicate is used at runtime, and the secure partition it is communicating with may provide services access through other means then the UEFI runtime services. As such, the MM communication library must not assume that the partition will be in the waiting state. Instead, it must handle the case where the partition is busy and retry the communication to some limit.

Observed issue

This specifically resolves a bugcheck observed booting to Windows on multiple platforms where the variable services are access through the runtime services at the same time that the TPM PPI is invoking StMM to access the PPI variables. This causes a busy response in the runtime services, which are not currently handled. The inverse is already handled as the ACPI FFH opregion handling for FF-A already accounts for busy responses.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

How This Was Tested

  • Boot to OS on ArmVirt
  • Boot to OS on physical platform

Integration Instructions

N/A

@cfernald cfernald requested review from Raymond-MS, kuqin12 and os-d June 17, 2026 19:26
@mu-automation

mu-automation Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

✅ QEMU Validation Passed

Source Dependencies

Repository Commit
mu_basecore 1abee8a
mu_tiano_platforms 2803dae

Results

Platform Target Build Boot Overall Boot Time Build Logs Boot Logs
Q35 DEBUG ✅ success ✅ success 0m 21s Build Logs Boot Logs
ArmVirt DEBUG ✅ success ✅ success 0m 14s Build Logs Boot Logs

Workflow run: https://github.com/microsoft/mu_basecore/actions/runs/27988252833

This comment was automatically generated by the Mu QEMU PR Validation workflow.

@os-d os-d left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Submit to edk2 in parallel?

@cfernald

Copy link
Copy Markdown
Contributor Author

Submit to edk2 in parallel?

Well, this is actually one of many issues with this function. It's the most pressing so prioritizing it. Thinking is that we need a more complete fix we can probably do upstream first.

@kuqin12

kuqin12 commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Tested on physical arm platform and booted to Windows 11 desktop.

Comment thread ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
Comment thread ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
MM communicate is used at runtime, and the secure partition it is communicating
with may provide services access through other means then the UEFI runtime
services. As such, the MM communication library must not assume that the
partition will be in the waiting state. Instead it must handle the case
where the partition is busy and retry the communication to some limit.

Signed-off-by: Chris Fernald <chfernal@microsoft.com>
@cfernald cfernald enabled auto-merge (rebase) June 22, 2026 22:40
@cfernald cfernald merged commit 8d72fb3 into microsoft:release/202511 Jun 22, 2026
56 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants