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: <20230623222353.3742384-1-evan@rivosinc.com> <20230624-mortally-parking-68f6bc1dd5ee@spud>
In-Reply-To: <20230624-mortally-parking-68f6bc1dd5ee@spud>
From:   Evan Green <evan@rivosinc.com>
Date:   Mon, 26 Jun 2023 12:25:42 -0700
Message-ID: <CALs-HstvXcwBa+h0u4mz_Pjm-bNd=9DX49Xy-=Fq0t3ECmAi2w@mail.gmail.com>
Subject: Re: [PATCH] RISC-V: Show accurate per-hart isa in /proc/cpuinfo
To:     Conor Dooley <conor@kernel.org>
Cc:     Palmer Dabbelt <palmer@rivosinc.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Andrew Jones <ajones@ventanamicro.com>,
        Anup Patel <apatel@ventanamicro.com>,
        Conor Dooley <conor.dooley@microchip.com>,
        Heiko Stuebner <heiko.stuebner@vrull.eu>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Sunil V L <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 Fri, Jun 23, 2023 at 5:12=E2=80=AFPM Conor Dooley <conor@kernel.org> wro=
te:
>
> Hey Evan,
>
> 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.

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

-Evan

>
> Cheers,
> Conor.