On 10/13/21 9:20 AM, Vineet Gupta wrote:
off topic but relates, for Zb (and similar things in the future) whats the strategy for change management/discovery. I understand you can hardcode things for quick test, but for a proper glibc implementation this would be an IFUNC but there seems to be no architectural way per spec (for software/kernel) to discover this.
Since the architecture restricted access to these CSRs, you do have to coordinate with the kernel.
There is an AT_HWCAP value that is given to userland, but it is currently masked to only provide a few of the MISA bits. This will need to be extended for both V and Zb. It doesn't help that Zb has been split into lots of smaller extensions, which (if done simplistically) will quickly consume all of the bits within AT_HWCAP.
So: I strongly suggest that RISC-V spend a few moments considering a way to represent this that will easily support the myriad extensions. One possibility is to add more AT_* entries straight away -- AT_HWCAP_ZB, which contains one bit for all of the Zb[abcs] extensions. Possibly set the "main" AT_HWCAP "b" bit if Zb is present at some minimal level.
Same issue is with building linux kernel with Zb - how do we make sure that hardware/sim supports Zb when running corresponding software.
On the kernel side this is easier -- read the CSRs then patch the kernel. There are existing ways to manage this sort of thing. r~
