On Wed, 13 Oct 2021 at 18:51, Richard Henderson < richard.hender...@linaro.org> wrote:
> 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~ >
