Re: [edk2-devel] ArmCallSmc() and SMCCC specification

["Leif Lindholm" <quic_llindhol@quicinc.com>]

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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-