Re: [PATCH] RISC-V: Show accurate per-hart isa in /proc/cpuinfo

From: Palmer Dabbelt
Date: Mon Jun 26 2023 - 16:48:27 EST


On Mon, 26 Jun 2023 13:34:24 PDT (-0700), Conor Dooley wrote:
On Mon, Jun 26, 2023 at 12:25:42PM -0700, Evan Green wrote:
On Fri, Jun 23, 2023 at 5:12 PM Conor Dooley <conor@xxxxxxxxxx> wrote:
> On Fri, Jun 23, 2023 at 03:23:53PM -0700, Evan Green wrote:
> > In /proc/cpuinfo, most of the information we show for each processor is
> > specific to that hart: marchid, mvendorid, mimpid, processor, hart,
> > compatible, and the mmu size. But the ISA string gets filtered through a
> > lowest common denominator mask, so that if one CPU is missing an ISA
> > extension, no CPUs will show it.
> >
> > Now that we track the ISA extensions for each hart, let's report ISA
> > extension info accurately per-hart in /proc/cpuinfo.
>
> No, you can't do this as it breaks the assumptions of userspace that
> this shows the set supported across all harts.
> Sorry, but NAK.

My hope was that we were still early enough that no production systems
existed (yet) that actually had different ISA extensions in the set we
track, and therefore usermode would have been unable to make those
assumptions at this point. If such a system exists, and I don't know
if it does or not, then I agree it's too late to make a change like
this.

You should put this information into your commit messages & not just
hope that people understand your intent.
Userspace does actually make these assumptions already, see for example
this Google "cpu features" repo:
https://github.com/google/cpu_features/tree/main
To be quite honest, I really dislike the fragility of what they have
implemented - with only one of the reasons being they made the mistake
of assuming homogeneity.

There's got to be a line somewhere for what constitutes buggy userspace
and what's a regression. Up to Palmer I suppose as to what constitutes
which.

Maybe let's just add a pretty printed version of the hwprobe info to /proc/cpuinfo, and then leave the ISA string alone as a legacy interface?

Having something so poorly defined as uABI is a bit embarassing, but it's our mistake so we've got to live with it.

I thought I'd put this out here and see if someone could point at such
a system; but if not it'd be great to keep /proc/cpuinfo accurate and
consistent with hwprobe (which does return accurate per-hart ISA
extension info).

Just another nail in the coffin for a bad interface :)
There are apparently some mixed c906 chips that support vector on one
core and not the other - although it is thead vector which is not
supported upstream yet...

Other than that, SiFive stuff technically can be mixed - rv64imac &
rv64imafdc on a bunch of the older stuff. I don't think anyone actually
runs those sort of configurations on them though.