Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230626-nature-seventh-6102e17bb4be@spud> <mhng-7656ce4f-bdcb-419c-8a77-18ab7d301cd7@palmer-ri-x1c9>
In-Reply-To: <mhng-7656ce4f-bdcb-419c-8a77-18ab7d301cd7@palmer-ri-x1c9>
From:   Evan Green <evan@rivosinc.com>
Date:   Mon, 26 Jun 2023 16:19:58 -0700
Message-ID: <CALs-HstCEFJD0xC1Ro8bjTL-bu4ramiXk5LZRr8QNsW1OcUZFA@mail.gmail.com>
Subject: Re: [PATCH] RISC-V: Show accurate per-hart isa in /proc/cpuinfo
To:     Palmer Dabbelt <palmer@dabbelt.com>
Cc:     Conor Dooley <conor@kernel.org>, aou@eecs.berkeley.edu,
        ajones@ventanamicro.com, apatel@ventanamicro.com,
        Conor Dooley <conor.dooley@microchip.com>,
        heiko.stuebner@vrull.eu, Paul Walmsley <paul.walmsley@sifive.com>,
        sunilvl@ventanamicro.com, linux-kernel@vger.kernel.org,
        linux-riscv@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jun 26, 2023 at 1:48=E2=80=AFPM Palmer Dabbelt <palmer@dabbelt.com>=
 wrote:
>
> 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=E2=80=AFPM Conor Dooley <conor@kernel.org=
> 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 process=
or is
> >> > > specific to that hart: marchid, mvendorid, mimpid, processor, hart=
,
> >> > > compatible, and the mmu size. But the ISA string gets filtered thr=
ough a
> >> > > lowest common denominator mask, so that if one CPU is missing an I=
SA
> >> > > extension, no CPUs will show it.
> >> > >
> >> > > Now that we track the ISA extensions for each hart, let's report I=
SA
> >> > > 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.

Fair enough.

> > 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?

I like it! I'll aim for that for v2. I'll resist the urge to name the
row isa_for_real.

>
> 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.