On Thu, Feb 16, 2023 at 5:30 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wed, Feb 15, 2023, at 23:43, Jessica Clarke wrote: > > On 15 Feb 2023, at 21:14, Evan Green <evan@xxxxxxxxxxxx> wrote: > >> On Wed, Feb 15, 2023 at 1:57 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> Palmer can probably speak to this with more authority, but my > >> understanding about the motivation for an approach like this goes > >> something like: > >> * With the nature of RISC-V, we expect a lot of these types of bits > >> and bobs, many more than we've seen with the likes of x86 and ARM. > > > > We’re already at (I think) 51 standard user-level extensions that LLVM > > knows about. > > Do you have an estimate of how many of these require kernel support > beyond identifying the extensions? > > >> * We also expect in some cases these values to be inconsistent across CPUs. > > > > That’s also true of some Arm SoCs. > > Right, but it's also something that we should not encourage, or > need to make easy to use. On arm64, the kernel support for having > asymmetric aarch32 mode was kept to an absolute minimum, and an > application is expected to get the information from /proc/cpuinfo > before pinning down a task to the correct subset of all CPUs. > > >> * So, a syscall with a vDSO function in front of it seemed like a > >> good combination of speed and flexibility. > >> > >> You're certainly right that HWCAPn would work for what we're exposing > >> today, so the question probably comes down to our relative predictions > >> of how this data will grow. > > > > The other big problem is vendor extensions. Since the key range can grow without accruing a process startup time penalty, this proposal handles vendor extensions fairly well, no? (Contrasting at least against hwcap bits, which once allocated have to be copied into every new process forever). > > My biggest concern is how this would be synchronized between the > interfaces that are available to users. What we have on other architectures > is a set of string identifiers in /proc/cpuinfo and a bitmask in HWCAP. > Ideally these are added in pairs so the information available to shell > scripts in human readers is the same that is available in the auxvec > data. > > Adding a third interface with the same information or a superset > requires more work in ensuring that each extension is available > in exactly the right places. Ideally I think there should be only > one table of possible CPU features so nobody has to make the > decision about which ones are important enough to add to one > interface or another. That makes sense. In this case, the proposal is that RISC-V would use this mechanism and generally abandon hwcap. So my hope is there should still only be about 2 spots to maintain. -Evan
