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.
Zb[abcs] will not be discoverable via MISA bits.
A unified low-level discovery mechanisms (and a way to inject this information to userspace via the auxiliary vector) are being developed at the moment.
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.
It looks like HWCAP, HWCAP2 and AT_PLATFORM and AT_BASE_PLATFORM will be used.
Kito presented the (then current) state of thinking at the Linux Plumbers Conference…
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~