MdeModulePkg/ArmFfaLib: add ArmFfaLibPartitionInfoGetRegs()

[LeviYeoReum]

This patch adds ArmFfaLibPartitionInfoGetRegs() in ArmFfaLib
As ArmFfaLibPartitionInfoGetRegs() is added, Normal world ArmFfLib Rx/Tx buffer is not a madatory.
That's why return EFI_UNSUPPORTED while Rx/Tx buffer mapping in ArmFfaLib constructor
can be consider as valid return If ARM_FFA_PARTITION_INFO_GET_REGS is supported by SPMC.

Patch #1 adds ArmFfaLibPartitionInfoGetRegs()
Patch #2 considers EFI_UNSUPPORTED while Rx/Tx buffer mapping in constrcutor as valid return
Patch #3 add helper function named ArmFfaLibGetPartitionInfo().
Patch #4-#6 applies ArmFfaLibGetPartitionInfo() in each modules.

Signed-off-by: Yeoreum Yun [email protected]

[tianocore-assign-reviewers]

⚠ WARNING: Cannot add some reviewers: A user specified as a reviewer for this PR is not a collaborator of the repository. Please add them as a collaborator to the repository so they can be requested in the future.

Non-collaborators requested:

• @arunsbaskaran
• @kuqin12
• @LeviYeoReum

Attn Admins:

• @jljusten
• @ardbiesheuvel
• @lgao4
• @mdkinney
• @makubacki
• @jkmathews
• @miki-intel-work

---

Admin Instructions:

• Add the non-collaborators as collaborators to the appropriate team(s) listed in teams
• If they are no longer needed as reviewers, remove them from Maintainers.txt

[kuqin12]

Not entirely related to this PR, but I was thinking about the usage of this library earlier. And it seems that the main churn for this library class comes from the Rx/Tx buffer, i.e. whether is supported, whether we have it in the right environment, whether we can have the correct framework to support the memory allocation, whether we need to unregister it when handing off to the OS, etc..

I would think for a large collection of basic FFA functionalities, it is really monitor calls + interpretation. We probably can keep it simple, then we can use it anywhere, link to all modules. But for Tx/Rx, which is like a global, and will need memory usage, and pass on the information of those buffers, it might be better to be handled separately.

TL;DR
Would it make better sense to create a Rx/Tx buffer library to specifically support RXTX_ related function IDs? To take one step further, would it be necessary to control the framework related information (Rx/Tx location, discovered Partition Info, etc.) through protocol/PPI in a module (i.e. PEI, DXE, STMM, etc.)

[LeviYeoReum]

Hmm. I'm not sure about "How to gather Rx/Tx related API". In case of GetPartitionInfo ABI, yes that's clear but What about direct message kind of API? Actaully these kind of API can be differ from the platform even the services whether it uses Rx/Tx buffer together or not. That's why at the first time, It seems too much to have separate library for Rx/Tx buffer I've separated it just with file.
Well. If there'll be addition of ABI in FF-A using Rx/Tx buffer (not related MEMORY management), it seems meaningful to have separation However, I don't think it's valuable to have it now.
Thanks.

Your response essentially means we can already do the separation :)

The implicit usage of Rx/Tx will still need to get Rx/Tx buffer information, which I think better fits into its own component. Whether that component is a set of modules (PEIM/DXE driver/Stmm) or a set of libraries for different phases, that is debatable.

I will not derail this PR further. But I might take a crack at it to see how much effort we will need to get that separated.

Well. I'll also take a time to think about it more (perhaps with Library? since for use in SEC phase too?)
Thanks to point this!

[LeviYeoReum]

@samimujawar and @kuqin12.

If you don't have anymore comment, Could you review and merge this patch series?

Thanks