SPCI is now called PSA FF-A.
Change-Id: Iaa10e0449edf5f6493ab21e648219392b17cc5ec
diff --git a/docs/Architecture.md b/docs/Architecture.md
index e0261d8..9c086eb 100644
--- a/docs/Architecture.md
+++ b/docs/Architecture.md
@@ -17,7 +17,7 @@
* Means for VMs to communicate with each other through message passing and
memory sharing, according to the Arm
- [Secure Partition Communication Interface (SPCI)](https://developer.arm.com/docs/den0077/a).
+ [Platform Security Architecture Firmware Framework for Arm v8-A (PSA FF-A)](https://developer.arm.com/docs/den0077/a).
* Emulation of some basic hardware features such as timers.
* A simple paravirtualised interrupt controller for secondary VMs, as they
don't have access to hardware interrupts.
@@ -156,7 +156,7 @@
Hafnium maintains state of which VM **owns** each page, and which VMs have
**access** to it. It does this using the stage 2 page tables of the VMs, with
some extra application-defined bits in the page table entries. A VM may share,
-lend or donate memory pages to another VM using the appropriate SPCI requests. A
+lend or donate memory pages to another VM using the appropriate FF-A requests. A
given page of memory may never be shared with more than two VMs, either in terms
of ownership or access. Thus, the following states are possible for each page,
for some values of X and Y:
diff --git a/docs/Manifest.md b/docs/Manifest.md
index 458b130..0912a6d 100644
--- a/docs/Manifest.md
+++ b/docs/Manifest.md
@@ -13,7 +13,7 @@
hypervisor {
compatible = "hafnium,hafnium";
- spci_tee;
+ ffa_tee;
vm1 {
debug_name = "name";
@@ -40,7 +40,7 @@
of memory, 4 CPUs and, by omitting the `kernel_filename` property, a kernel
preloaded into memory. The primary VM is given all remaining memory, the same
number of CPUs as the hardware, a kernel image called `vmlinuz` and a ramdisk
-`initrd.img`. Secondaries cannot have a ramdisk. SPCI memory sharing with the
+`initrd.img`. Secondaries cannot have a ramdisk. FF-A memory sharing with the
TEE is enabled.
```
@@ -50,7 +50,7 @@
hypervisor {
compatible = "hafnium,hafnium";
- spci_tee;
+ ffa_tee;
vm1 {
debug_name = "primary VM";
diff --git a/docs/SchedulerExpectations.md b/docs/SchedulerExpectations.md
index 7dfe193..f642c94 100644
--- a/docs/SchedulerExpectations.md
+++ b/docs/SchedulerExpectations.md
@@ -10,85 +10,85 @@
The scheduler VM is responsible for scheduling the vCPUs of all the other VMs.
It should request information about the VMs in the system using the
-`SPCI_PARTITION_INFO_GET` function, and then schedule their vCPUs as it wishes.
+`FFA_PARTITION_INFO_GET` function, and then schedule their vCPUs as it wishes.
The recommended way of doing this is to create a kernel thread for each vCPU,
-which will repeatedly run that vCPU by calling `SPCI_RUN`.
+which will repeatedly run that vCPU by calling `FFA_RUN`.
-`SPCI_RUN` will return one of several possible functions, which must be handled
+`FFA_RUN` will return one of several possible functions, which must be handled
as follows:
-### `SPCI_INTERRUPT`
+### `FFA_INTERRUPT`
The vCPU has been preempted but still has work to do. If the scheduling quantum
has not expired, the scheduler MUST call `hf_vcpu_run` on the vCPU to allow it
to continue.
-### `SPCI_YIELD`
+### `FFA_YIELD`
The vCPU has voluntarily yielded the CPU. The scheduler SHOULD take a scheduling
decision to give cycles to those that need them but MUST call `hf_vcpu_run` on
the vCPU at a later point.
-### `SPCI_MSG_WAIT`
+### `FFA_MSG_WAIT`
The vCPU is blocked waiting for a message. The scheduler MUST take it off the
-run queue and not call `SPCI_RUN` on the vCPU until it has either:
+run queue and not call `FFA_RUN` on the vCPU until it has either:
* injected an interrupt
* sent it a message
-* received `HF_SPCI_RUN_WAKE_UP` for it from another vCPU
-* the timeout provided in `w2` is not `SPCI_SLEEP_INDEFINITE` and the
+* received `HF_FFA_RUN_WAKE_UP` for it from another vCPU
+* the timeout provided in `w2` is not `FFA_SLEEP_INDEFINITE` and the
specified duration has expired.
-### `SPCI_MSG_SEND`
+### `FFA_MSG_SEND`
A message has been sent by the vCPU. If the recipient is the scheduler VM itself
then it can handle it as it pleases. Otherwise the scheduler MUST run a vCPU
from the recipient VM and priority SHOULD be given to those vCPUs that are
-waiting for a message. The scheduler should call SPCI_RUN again on the sending
+waiting for a message. The scheduler should call FFA_RUN again on the sending
VM as usual.
-### `SPCI_RX_RELEASE`
+### `FFA_RX_RELEASE`
The vCPU has made the mailbox writable and there are pending waiters. The
scheduler MUST call `hf_mailbox_waiter_get()` repeatedly and notify all waiters
by injecting an `HF_MAILBOX_WRITABLE_INTID` interrupt. The scheduler should call
-SPCI_RUN again on the sending VM as usual.
+FFA_RUN again on the sending VM as usual.
-### `HF_SPCI_RUN_WAIT_FOR_INTERRUPT`
+### `HF_FFA_RUN_WAIT_FOR_INTERRUPT`
-_This is a Hafnium-specific function not part of the SPCI standard._
+_This is a Hafnium-specific function not part of the FF-A standard._
The vCPU is blocked waiting for an interrupt. The scheduler MUST take it off the
-run queue and not call `SPCI_RUN` on the vCPU until it has either:
+run queue and not call `FFA_RUN` on the vCPU until it has either:
* injected an interrupt
-* received `HF_SPCI_RUN_WAKE_UP` for it from another vCPU
-* the timeout provided in `w2` is not `SPCI_SLEEP_INDEFINITE` and the
+* received `HF_FFA_RUN_WAKE_UP` for it from another vCPU
+* the timeout provided in `w2` is not `FFA_SLEEP_INDEFINITE` and the
specified duration has expired.
-### `HF_SPCI_RUN_WAKE_UP`
+### `HF_FFA_RUN_WAKE_UP`
-_This is a Hafnium-specific function not part of the SPCI standard._
+_This is a Hafnium-specific function not part of the FF-A standard._
Hafnium would like `hf_vcpu_run` to be called on another vCPU, specified by
`hf_vcpu_run_return.wake_up`. The scheduler MUST either wake the vCPU in
question up if it is blocked, or preempt and re-run it if it is already running
somewhere. This gives Hafnium a chance to update any CPU state which might have
-changed. The scheduler should call SPCI_RUN again on the sending VM as usual.
+changed. The scheduler should call FFA_RUN again on the sending VM as usual.
-### `SPCI_ERROR`
+### `FFA_ERROR`
-#### `SPCI_ABORTED`
+#### `FFA_ABORTED`
The vCPU has aborted triggering the whole VM to abort. The scheduler MUST treat
-this the same as `HF_SPCI_RUN_WAKE_UP` for all the other vCPUs of the VM. For
-this vCPU the scheduler SHOULD either never call SPCI_RUN on the vCPU again, or
-treat it the same as `HF_SPCI_RUN_WAIT_FOR_INTERRUPT`.
+this the same as `HF_FFA_RUN_WAKE_UP` for all the other vCPUs of the VM. For
+this vCPU the scheduler SHOULD either never call FFA_RUN on the vCPU again, or
+treat it the same as `HF_FFA_RUN_WAIT_FOR_INTERRUPT`.
#### Any other error code
-This should not happen if the scheduler VM has called `SPCI_RUN` correctly, but
+This should not happen if the scheduler VM has called `FFA_RUN` correctly, but
in case there is some other error it should be logged. The scheduler SHOULD
either try again or suspend the vCPU indefinitely.
@@ -102,6 +102,6 @@
timer (PPI 10, IRQ 26).
* Forward interrupts intended for secondary VMs to an appropriate vCPU of the
VM by calling `hf_interrupt_inject` and then running the vCPU as usual with
- `SPCI_RUN`. (If the vCPU is already running at the time that
+ `FFA_RUN`. (If the vCPU is already running at the time that
`hf_interrupt_inject` is called then it must be preempted and run again so
that Hafnium can inject the interrupt.)
diff --git a/docs/StyleGuide.md b/docs/StyleGuide.md
index 770d978..1619971 100644
--- a/docs/StyleGuide.md
+++ b/docs/StyleGuide.md
@@ -38,7 +38,7 @@
These rules apply to comments and other natural language text.
* Capitalize acronyms.
- * CPU, vCPU, VM, EL2, SPCI, QEMU
+ * CPU, vCPU, VM, EL2, FF-A, QEMU
* Spell out Hafnium in full, not Hf.
* Use single spaces.
* Sentences end with full stops.
diff --git a/docs/VmInterface.md b/docs/VmInterface.md
index 47de251..f061ebc 100644
--- a/docs/VmInterface.md
+++ b/docs/VmInterface.md
@@ -100,7 +100,7 @@
## Asynchronous message passing
VMs will be able to send messages of up to 4 KiB to each other asynchronously,
-with no queueing, as specified by SPCI.
+with no queueing, as specified by FF-A.
## Memory
@@ -164,7 +164,7 @@
## TrustZone communication
The primary VM will be able to communicate with a TEE running in TrustZone
-either through SPCI messages or through whitelisted SMC calls, and through
+either through FF-A messages or through whitelisted SMC calls, and through
shared memory.
## Other SMC calls