Hi Andrew,
I don't think Hafnium implements the different cacheability and shareability types for memory sharing at all does it?
[JA] No, it doesn't. At least that is my understanding as well. I noticed mostly due to lack of support in the mm library. Asking was a means to confirm.
The point (at least for now) was just about validation of the respective fields in the memory transaction descriptor.
Thank you for this! 🙂
Best regards,
João
________________________________
From: Andrew Walbran
Sent: Wednesday, July 14, 2021 5:29 PM
To: Joao Alves
Cc: hafnium(a)lists.trustedfirmware.org; Olivier Deprez; Achin Gupta; Mahesh Reddy Bireddy; Jaykumar Pitambarbhai Patel
Subject: Re: Hafnium - Memory attributes precedence checks for mem share
I don't think Hafnium implements the different cacheability and shareability types for memory sharing at all does it? We just didn't have a need for it, if you want to add support that should be fine.
This is mentioned in https://developer.trustedfirmware.org/T827, you can assign that to yourself if you want to take it on.
On Wed, 14 Jul 2021 at 13:50, Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote:
Hi Andrew,
We have been revising some aspects of the memory sharing implementation. The specification describes a set of precedence rules for the memory attributes specified in the memory transaction descriptor, including: Memory type, cacheability, shareability.
The sender would fill the memory attributes for the region to be shared. After memory send, the receiver should retrieve the regions, filling the memory attributes on its transaction descriptor that comply with the referred precedence rules.
The referred rules can be found in section 10.10.4 of the newly release FF-A v1.1 beta spec<https://developer.arm.com/documentation/den0077/c/?lang=en>, as follows.
Memory type precedence rules ( < reads as is less permissive than):
* Device-nGnRnE < Device-nGnRE < Device-nGRE < Device-GRE < Normal
Cacheability precedence rules:
* Non-cacheable < Write-Back Cacheable
Shareability precedence rules:
* Non-Shareable < Inner Shareable < Outer shareable
These checks are not part of the handling of FFA_MEMORY_RETRIEVE_REQ.
Was there an implementation defined reason for this? If so, could you please provide the rationale?
Thank you in advance for your help.
Best regards,
João Alves
Hi Andrew,
We have been revising some aspects of the memory sharing implementation. The specification describes a set of precedence rules for the memory attributes specified in the memory transaction descriptor, including: Memory type, cacheability, shareability.
The sender would fill the memory attributes for the region to be shared. After memory send, the receiver should retrieve the regions, filling the memory attributes on its transaction descriptor that comply with the referred precedence rules.
The referred rules can be found in section 10.10.4 of the newly release FF-A v1.1 beta spec<https://developer.arm.com/documentation/den0077/c/?lang=en>, as follows.
Memory type precedence rules ( < reads as is less permissive than):
* Device-nGnRnE < Device-nGnRE < Device-nGRE < Device-GRE < Normal
Cacheability precedence rules:
* Non-cacheable < Write-Back Cacheable
Shareability precedence rules:
* Non-Shareable < Inner Shareable < Outer shareable
These checks are not part of the handling of FFA_MEMORY_RETRIEVE_REQ.
Was there an implementation defined reason for this? If so, could you please provide the rationale?
Thank you in advance for your help.
Best regards,
João Alves
