Received-SPF: pass (google.com: domain of linux-kernel+bounces-104146-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 15 Mar 2024 09:11:35 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Inochi Amaoto <inochiama@outlook.com>
Cc: Conor Dooley <conor@kernel.org>, Qingfang Deng <dqfext@gmail.com>, 
	Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Albert Ou <aou@eecs.berkeley.edu>, Atish Patra <atishp@atishpatra.org>, 
	Anup Patel <anup@brainfault.org>, Will Deacon <will@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, Conor Dooley <conor.dooley@microchip.com>, 
	Heiko Stuebner <heiko@sntech.de>, Guo Ren <guoren@kernel.org>, linux-riscv@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] perf: RISC-V: fix IRQ detection on T-Head C908
Message-ID: <20240315-73aa13079ef83a4559869084@orel>
References: <20240311063018.1886757-1-dqfext@gmail.com>
 <IA1PR20MB4953ECC3E32E95303872CD14BB242@IA1PR20MB4953.namprd20.prod.outlook.com>
 <CALW65jZ+q8sDiRKgsRL9n+939HNUCnkKuO=YJjHB5Js=WYQeOg@mail.gmail.com>
 <20240312-evil-resource-66370b68b9b4@spud>
 <IA1PR20MB4953CE8999960BA71B46DE6CBB2A2@IA1PR20MB4953.namprd20.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <IA1PR20MB4953CE8999960BA71B46DE6CBB2A2@IA1PR20MB4953.namprd20.prod.outlook.com>

On Wed, Mar 13, 2024 at 09:31:26AM +0800, Inochi Amaoto wrote:
..
> IMHO, it may be better to use a new DT property like "riscv,cpu-errata" or
> "<vendor>,cpu-errata". It can achieve almost everything like using pseudo
> isa. And the only cost I think is a small amount code to parse this.
>

What's the ACPI equivalent for this new DT property? If there isn't one,
then the cost is also to introduce something to the ACPI spec and add the
ACPI parsing code.

I'd much rather we call specified behaviors "extensions", whether they
are vendor-specific or RVI standard, and then treat all extensions the
same way in hardware descriptions and Linux. It'd also be best if errata
in extension implementations were handled by replacing the extension in
the hardware description with a new name which is specifically for the
behavior Linux should expect. (Just because two extensions are almost the
same doesn't mean we should say we have one and then have some second
mechanism to say, "well, not really, instead of that, it's this". It's
cleaner to just remove the extension it doesn't properly implement from
its hardware description and create a name for the behavior it does have.)

Errata in behaviors which don't have extension names (are hopefully few)
and are where mvendorid and friends would need to be checked, but then why
not create a pseudo extension name, as Conor suggests, so the rest of
Linux code can manage errata the same way it manages every other behavior?

The growth rate of the ISA bitmap is worth thinking about, though, since
we have several copies of it (at least one "all harts" bitmap, one bitmap
for each hart, another one for each vcpu, and then there's nested virt...)
We don't have enough extensions to worry about it now, but we can
eventually try partitioning, using common maps for common bits, not
storing bits which can be inferred from other bits, etc.

Thanks,
drew