Extending FF-A definitions

[kuqin12]

Description

This change adds a minor extension to existing FF-A definitions. This will allow the UEFI to accept FF-A notification related operations.

• Breaking change?
  • Breaking change - Does this PR cause a break in build or boot behavior?
  • Examples: Does it add a new library class or move a module to a different repo.
• Impacts security?
  • Security - Does this PR have a direct security impact?
  • Examples: Crypto algorithm change or buffer overflow fix.
• Includes tests?
  • Tests - Does this PR include any explicit test code?
  • Examples: Unit tests or integration tests.

How This Was Tested

This was tested on QEMU SBSA platform with a test application for FF-A notificaiton.

Integration Instructions

N/A

[leiflindholm]

Commit message typo: APL1 should be ALP1.

I was going to say something about merging updates based on an alpha-maturity specification, but ... Arm has published it on developer.arm.com and the revision history suggests this is normal.

[kuqin12]

Sure, will update.

[kuqin12]

The commit message is updated to include this change and additional reference to the FF-A memory protocol.

[leiflindholm]

Maybe I'm being dense, but searching through the referenced document, I can't find these bit definitions. Can you point to where in the spec these values/offsets are defined?

[kuqin12]

Maybe I'm being dense, but searching through the referenced document, I can't find these bit definitions. Can you point to where in the spec these values/offsets are defined?

not a problem :)

• ARM_FFA_NOTIFICATIONS_FLAG_PER_VCPU: is from the "Table 16.19", where it describes the flags: Bit[0]: Per-vCPU notification flag

• ARM_FFA_NOTIFICATIONS_FLAG_DELAY_SRI: is from the "Table 16.19", where it describes the flags: Bit[1]: Delay Schedule Receiver interrupt flag

• ARM_FFA_NOTIFICATIONS_FLAGS_VCPU_ID is from the "Table 16.23", where it describes " Bit[31:16]: Receiver vCPU ID", as well as "Table 16.19", where it describes "Bit[31:16]: Receiver vCPU ID when Bit[0] is 1."

• ARM_FFA_NOTIFICATIONS_FLAG_BITMAP_* are from "Table 16.23", where in "uint32 Flags" section, it describes the bitmap of which receiver type this notification is for.

• ARM_FFA_FEATURE_* are from "Table 13.13", where the "FF-A Feature Name"s are referring to.

• ARM_FFA_MEM_PERM_RESERVED_MASK is a miss. It actually comes from the memory protocol spec (1.3 ALP1) and "Table 2.39" describes the memory permission will only take the lower 3 bits.

[leiflindholm]

Ah, that explains it.
Hmm, so some fields are shared between the SET and GET functions and some are not.
That spec gets a bit messy.

I was going to suggest changing
ARM_FFA_NOTIFICATIONS_FLAG as
ARM_FFA_NOTIFICATION_GETSET_FLAG
for the ones available for both functions, and _GET/_SET for the function-specific ones.
But I don't think that actually helps readability or cross-referencability.
However, could you drop the S from NOTIFICATIONS so it matches the spec?

The feature ones are fine. But could you add a mention of the memory protocol spec to the commit message?

[kuqin12]

Ah, that explains it. Hmm, so some fields are shared between the SET and GET functions and some are not. That spec gets a bit messy.

I was going to suggest changing ARM_FFA_NOTIFICATIONS_FLAG as ARM_FFA_NOTIFICATION_GETSET_FLAG for the ones available for both functions, and _GET/_SET for the function-specific ones. But I don't think that actually helps readability or cross-referencability. However, could you drop the S from NOTIFICATIONS so it matches the spec?

The feature ones are fine. But could you add a mention of the memory protocol spec to the commit message?

This is updated. I also added a few extra comments to refer to the section where these definitions are found. Hopefully this will be easier to correlate to where the definition is rooted from the spec.