Context
The AArch64 SPMC serves one Normal-world FF-A endpoint, id 0. The SPMD answers FFA_ID_GET with 0. The SPMC refuses a direct request, an RX/TX unmap, or an RX release that names any other Normal-world id. Running several managed guests on Cortex-A, as the Cortex-M ports do, needs a Hypervisor at NS-EL2 that allocates VM ids (DEN0077A sections 6.1 and 6.3). The SPMC must accept those ids.
Origin
PR #29 review (multi-guest on AArch64)
What is needed
- SPMC accepts Hypervisor-allocated VM ids other than 0 for direct requests, memory transactions and RX buffer management
- Per-VM notification bitmaps (FF-A 1.2 sections 10.4 and 10.10)
- The VM_CREATED and VM_DESTROYED framework messages to subscribed partitions (section 18.3)
- Per-VM PSA client identity
- Validation with an EL2 test dispatcher like the ACS vm1, not a third-party Hypervisor
Blockers and dependencies
#29 merges first. Real dual-RTOS demos wait until a Hypervisor that relays FF-A is chosen.
Acceptance criteria
- Host rows for the VM id rules
- A QEMU scenario where two VM ids reach Secure Partitions and are kept apart
- The single-endpoint deviation in docs/Security-Model.md and docs/FF-A-Compatibility.md is updated
Context
The AArch64 SPMC serves one Normal-world FF-A endpoint, id 0. The SPMD answers FFA_ID_GET with 0. The SPMC refuses a direct request, an RX/TX unmap, or an RX release that names any other Normal-world id. Running several managed guests on Cortex-A, as the Cortex-M ports do, needs a Hypervisor at NS-EL2 that allocates VM ids (DEN0077A sections 6.1 and 6.3). The SPMC must accept those ids.
Origin
PR #29 review (multi-guest on AArch64)
What is needed
Blockers and dependencies
#29 merges first. Real dual-RTOS demos wait until a Hypervisor that relays FF-A is chosen.
Acceptance criteria