Received-SPF: pass (google.com: domain of linux-kernel+bounces-107600-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 19 Mar 2024 14:39:21 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Conor Dooley <conor@kernel.org>
Cc: Atish Patra <atishp@rivosinc.com>, 
	Inochi Amaoto <inochiama@outlook.com>, 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: <20240319-3e72d732cbf2fcf1cb81f968@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>
 <20240315-73aa13079ef83a4559869084@orel>
 <2de56d8b-bc78-428b-9c09-4729b269fa41@rivosinc.com>
 <20240318-such-animal-bf33de12dc3a@spud>
 <4bdaaff1-13ec-48c2-b165-6a8255784aef@rivosinc.com>
 <20240319-worry-video-66589b3ed8ae@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240319-worry-video-66589b3ed8ae@spud>

On Tue, Mar 19, 2024 at 09:06:34AM +0000, Conor Dooley wrote:
> On Mon, Mar 18, 2024 at 05:48:13PM -0700, Atish Patra wrote:
> > On 3/18/24 16:48, Conor Dooley wrote:
> > > On Mon, Mar 18, 2024 at 03:46:54PM -0700, Atish Patra wrote:
> 
> > > > For 2.b, either we can start defining pseudo extensions or adding
> > > > vendor/arch/impid checks.
> > > > 
> > > > @Conor: You seems to prefer the earlier approach instead of adding the
> > > > checks. Care to elaborate why do you think that's a better method compared
> > > > to a simple check ?
> > > 
> > > Because I don't think that describing these as "errata" in the first
> > > place is even accurate. This is not a case of a vendor claiming they
> > > have Sscofpmf support but the implementation is flawed. As far as I
> > > understand, this is a vendor creating a useful feature prior to the
> > > creation of a standard extension.
> > > A bit of a test for this could be "If the standard extension never
> > > existed, would this be considered a new feature or an implementation
> > > issue". I think this is pretty clearly in the former camp.
> > > 
> > 
> > So we have 3 cases.
> > 
> > 1. Pseudo extension: An vendor extension designed and/or implemented before
> > the standard RVI extension was ratified but do not violate any standard
> > encoding space.

The vendor should name these extensions themselves.

> > 
> > 2. Erratas: An genuine bug/design issue in the expected behavior from a
> > standard RVI extension (including violating standard encoding space)

More on this below, but I think vendors should name these too.

> > 
> > 3. Vendor extension: A new or a variant of standard RVI extension which is
> > different enough from standard extension.
> > 
> > IMO, the line between #2 and #1 may get blurry as we going forward because
> > of the sheer number of small extensions RVI is comping up with (which is a
> > problem as well).

The line between #1 and #2 is blurry because the only difference is the
original intentions. The end result is that a vendor has implemented
something that resembles a standard extension, but is not the same as the
standard extension.

> 
> Aye, I think some of that is verging on ridiculous.
> 
> > Just to clarify: I am not too worried about this particular case as we know
> > that T-head's implementation predates the Sscofpmf extension.
> > But once we define a standard mechanism for this kind of situation, vendor
> > may start to abuse it.
> 
> How do you envisage it being abused by a vendor?
> Pre-dating the standard extension does make this one fairly clear-cut,
> but are you worried about people coming along and claiming to implement
> XConorSscofpmf instead of Sscofpmf rather than suffer the "shame" of a
> broken implementation?

Other than the concern of the ballooning bitmap, I'd prefer this approach.
If a vendor has implemented some extension which happens to be "almost
Sscofpmf", then whether it was implemented before the Sscofpmf spec
existed, or after, isn't really important. What's important is that it's
only "almost Sscofpmf" and not _exactly_ Sscofpmf, which means it should
not use the Sscofpmf extension name. Since vendors are allowed to create
their own XVendor names, then that shouldn't be a problem. Indeed, the
abuse concern seems to be in the opposite direction, that vendors will
try to pass off almost-standard extensions as standard extensions by
trying to get workarounds into Linux. Maybe Linux policy should be to
simply reject workarounds to extensions, requiring vendors to create new
names instead.

> All this stuff is going to be pretty case-by-case (to begin with at
> least) so I'm not too worried about that sort of abuse.

Case-by-case is reasonable, since it's probably too strict to always
require new names. We can consider each proposed workaround as they
come, but it's a slippery slope once workarounds are accepted.

Thanks,
drew