Hi Olivier/Andrew,
On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium hafnium@lists.trustedfirmware.org wrote:
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/hy...
What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with the SMC32 convention.
Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features?
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked.
For other functions I guess we could make it support either, by discarding the SMC convention bit in FFA_FEATURES as you suggest. Are there any other differences between the SMC32 and SMC64 convention which we need to take care of?
I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc.
Cheers, Achin
-- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium
On Wed, 22 Jul 2020 at 17:27, Achin Gupta Achin.Gupta@arm.com wrote:
Hi Olivier/Andrew,
On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <
hafnium@lists.trustedfirmware.org> wrote:
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/hy...
What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with the SMC32 convention.
Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features?
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked.
Hafnium does not currently support AArch32 VMs. Support for AArch32 VMs or SPs could be added (and I think there was some plan from Arm to do so?) but will require quite a bit more than just changing the function IDs.
For other functions I guess we could make it support either, by discarding
the SMC convention bit in FFA_FEATURES as you suggest. Are there any
other
differences between the SMC32 and SMC64 convention which we need to take care of?
I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc.
Good point, I didn't notice that many of the functions don't have 64-bit versions. Did this change at some point? I thought they used to mostly have both.
Hi Andrew,
On 22 Jul 2020, at 17:34, Andrew Walbran qwandor@google.com wrote:
On Wed, 22 Jul 2020 at 17:27, Achin Gupta Achin.Gupta@arm.com wrote: Hi Olivier/Andrew,
On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium hafnium@lists.trustedfirmware.org wrote:
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/hy...
What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with the SMC32 convention.
Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features?
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked. Hafnium does not currently support AArch32 VMs. Support for AArch32 VMs or SPs could be added (and I think there was some plan from Arm to do so?) but will require quite a bit more than just changing the function IDs.
Absolutely.
For other functions I guess we could make it support either, by discarding the SMC convention bit in FFA_FEATURES as you suggest. Are there any other differences between the SMC32 and SMC64 convention which we need to take care of?
I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc. Good point, I didn't notice that many of the functions don't have 64-bit versions. Did this change at some point? I thought they used to mostly have both.
The general rule in Arm specs is that if an ABI does not have an address parameter, only the SMC32 FID is allocated. Else both are allocated. But yeah, this was not explicitly discussed :(
Cheers, Achin
On Wed, 22 Jul 2020 at 17:55, Achin Gupta Achin.Gupta@arm.com wrote:
Hi Andrew,
On 22 Jul 2020, at 17:34, Andrew Walbran qwandor@google.com wrote:
On Wed, 22 Jul 2020 at 17:27, Achin Gupta Achin.Gupta@arm.com wrote: Hi Olivier/Andrew,
On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <
hafnium@lists.trustedfirmware.org> wrote:
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean :
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/hy...
What is the rationale behind this? As per the SMCCC: -1 must be returned
for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with
the
SMC32 convention.
Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features?
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit
addresses
for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a
requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked.
Hafnium does not currently support AArch32 VMs. Support for AArch32 VMs
or SPs could be added (and I think there was some plan from Arm to do so?) but will require quite a bit more than just changing the function IDs.
Absolutely.
For other functions I guess we could make it support either, by
discarding
the SMC convention bit in FFA_FEATURES as you suggest. Are there any
other
differences between the SMC32 and SMC64 convention which we need to
take
care of?
I think we need to make a more informed choice. For example, what if
FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc.
Good point, I didn't notice that many of the functions don't have 64-bit
versions. Did this change at some point? I thought they used to mostly have both.
The general rule in Arm specs is that if an ABI does not have an address parameter, only the SMC32 FID is allocated. Else both are allocated. But yeah, this was not explicitly discussed :(
That seems reasonable and should be easy to fix, I just didn't realise it.
hafnium@lists.trustedfirmware.org
-
Achin Gupta -
Andrew Walbran