Hi Marcin. A few high-level thoughs below.
On 2024-05-31 08:14, Marcin Juszkiewicz wrote:
EDK2/ArmPkg/Library/ArmSmcLib has code to do SMC calls.There are ArmCallSmc[0-3]() functions for up to 3 arguments/results and ArmCallSmc() function which can use 7 arguments and get 4 results back.This implementation looks like version B (Nov 2016) of SMCCC specification [1] with one more register used.1. https://developer.arm.com/documentation/den0028/b/In 2020 we got version C of spec (and then D, E, F) which allows to use more registers:> Allow R4—R7 (SMC32/HVC32) to be used as result registers. > Allow X8—X17 to be used as parameter registers in SMC64/HVC64. > Allow X4—X17 to be used as result registers in SMC64/HVC64.And I started to wonder how to update EDK2 to newer version of SMCCC spec as one of in-progress QemuSbsa SMC calls may return more than 4 values.
Yes, definitely. This has been a wishlist item for some time, but in reality we've only ever updated these when we needed new functionality.
ARM_SMC_ARGS in ArmSmcLib.h can be expanded to handle up to Arg17 in an easy way and guarded by "#if defined(__aarch64__)" to not change it on Arm32.Then ArmCallSmc() in {AArch64,Arm}/ArmSmc.S needs changes. But here it gets tricky.On Arm we preserve r4-r8 and restore them after call like spec says. Which we do not do on AArch64 as version B of spec did not required that (and this changed in version C).If we start handling more than 4 results then we need to know how many results are expected and restore rest of r4-r7/x4-x17 registers:
Yeah, it feels like we may want to add a version field or/and number of registers to save/restore to a new struct. And we should definitely align Arm/AArch64 behaviour.
From what I saw in both edk2/ and edk2-platforms/ most of code uses ArmCallSmc() function with ARM_SMC_ARGS structure populared with arguments. ArmCallSmc[0-3]() are used by Smbios, Psci and QemuSbsa code only.
The ArmCallSmc[0-3] helpers were only added as shorthand for most common cases. I don't think we should worry about how those work for making any design decisions. Everything they do can be described by the main ArmCallSmc functions and a few lines of struct stuffing.
Now the question is: how to handle change?
It could be that it would be easiest to add a new call function, and maybe even ra new egister struct, than trying to adapt the existing ones in ways that doesn't break existing users?
That is if we care about existing users. We could always modify it to guarantee breakage and expect users to update their code. Since this is a library, and not a protocol, we *mostly* don't need to worry about users mixing prebuilt binaries using old structs with new functions.
We could add ArmCallSmc[4-17] but that name only tells how many arguments we pass to SMC call, not how many results we expect. Or should we add NumberOfResults argument to ArmCallSmc() to know which registers we should preserve and which are results? And how complicated this assembly function will become?
I don't think the assembly function needs to be that complicated. It'd be a bit tedious with a bunch of tests, but...
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119431): https://edk2.groups.io/g/devel/message/119431
Mute This Topic: https://groups.io/mt/106403741/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
