qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 11/26] target/riscv: Add orc.b instruction for Zbb, removing g


From: Richard Henderson
Subject: Re: [PULL 11/26] target/riscv: Add orc.b instruction for Zbb, removing gorc/gorci
Date: Wed, 13 Oct 2021 09:51:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]