From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B80ADC54E5D for ; Tue, 19 Mar 2024 13:39:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3qEkv+SXuJyhDasvu8i+kJ+0UIzFXZmuZu+he+BqzqY=; b=Ut7I2rkLzo3I79 R2nIT2XrPPca9z/FF0q9zm0SMuENtKgRXc7Udi+VgQwdMCtXL+1OiqZ+nvbEzKAhVsdsJPbQCifGg JZrgAQVb6u6LlBGWPbJIiA18DkL1T4UGOAOiGrxACFY5KbSgGAOl31LX7HGtnqqUY4ycf1g+bKeWP WmxWkSH6osYyZYz8kbcTkJMD3s/YXqgz91LlM/MYJok+Buwtsdlc1ZCBfVddAG2jZFtFI2pHnTyN8 1YNGUJi8WLb1GnZmnxePvv8Z8PKT53ps+uCyYplNS/mHr41VUXP63//aEDtNgFkuHd+joPLJDLmbo 2BQ40T2uFjc2j811Nj/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmZgf-0000000CpUc-49FK; Tue, 19 Mar 2024 13:39:29 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmZgb-0000000CpSi-16Ax for linux-arm-kernel@lists.infradead.org; Tue, 19 Mar 2024 13:39:28 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-56ba6c83805so100665a12.0 for ; Tue, 19 Mar 2024 06:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1710855563; x=1711460363; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4zAsS/uNen1I904a04qYYT/TYDmbVxX/Uth0W4MlTuw=; b=OrF0lkz1fOEPVKzHE8lonFuAZTgf9d/SWNHmINPRp318+g7yNJZ9avlCKRcyYVPXQy I4Mv4EYvBJZPvyjPr+N62VA8vYc0DaiJK+10qU+3r3T87nSCBdASYn+4/z+9qKvqWkOR 7kvhxVverdJ61OhXac/fJ/qexgIkzVnC7xDJRL4l7bOdvVXaCPhemNsWcbiuZuuEsHeA V0TO/sRAvHYR+C6BPPwFTWkQtTpdYQnrv11qieJt86rZBcN+0ljYb83fH2E2bKVsCrfC RftRDF7r8NHKPh22zTbM6cw7AzICrJZCIfX4E7l9O2AM16SOhiybxpAPONVerWPXCLAJ zn4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710855563; x=1711460363; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4zAsS/uNen1I904a04qYYT/TYDmbVxX/Uth0W4MlTuw=; b=uEB3UPR4hSA2REhdToCaww3ODMM3AufprdPLKtxYDBzgESE+/+/q/sdrK0I7l6V1KX nTU5zcQLYMVw6M/oTt804EcfWLG2lC0ZpGK89LyFZAfgNstBgF4rDzCbncUDJHiWsLfV Ufqm1Ke8rS4VE9VaxrrzyBFOfLs+8SDerTMSBEIxOSOg9I6Ru42d8zi8zR778qyVPUX3 m9TUqYcmdGil363tbdSnb1Hhq0La28rHyIiHTYV+792PrlRWhT9/jKusA16FIDJHWFu1 FqbuQwTm5foyoAAQo3tpymoW/tGvBsiOlyiOCJKO4/CsBV8VaMxgF1jUviHJ+ZuELAaD q4mg== X-Forwarded-Encrypted: i=1; AJvYcCV35xNRlfs539jL6VTAPvfPQCyYuSCYlp2T7FMVc6RRVsv4Lektm2IH38BUwpUf9iu14eUSOgyBn2dNq6EGAgyVRo77gfkDntLzPkeMX9XqSGMMnE8= X-Gm-Message-State: AOJu0YyGEMCnB+iwDZD2MAHfRQQnt8oFjYNlRtwlhyUCklTPGQ/1NNT8 KBpYtl5jsOWRz3WAR+PLwrKnwIFpWuw6TVvjzp2+oKpjLci/pZubjpTyj8Mukss= X-Google-Smtp-Source: AGHT+IHVRMJgWhA6FUGYuB3YQ2YkT+vT6+CMMifWJKwecbxw4bHQrbgtLR+eeZnyMUCHzJq6zdMjMg== X-Received: by 2002:a05:6402:5516:b0:568:1248:9f49 with SMTP id fi22-20020a056402551600b0056812489f49mr11014066edb.18.1710855562942; Tue, 19 Mar 2024 06:39:22 -0700 (PDT) Received: from localhost (2001-1ae9-1c2-4c00-20f-c6b4-1e57-7965.ip6.tmcz.cz. [2001:1ae9:1c2:4c00:20f:c6b4:1e57:7965]) by smtp.gmail.com with ESMTPSA id er27-20020a056402449b00b00568d2518105sm2756561edb.12.2024.03.19.06.39.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Mar 2024 06:39:22 -0700 (PDT) Date: Tue, 19 Mar 2024 14:39:21 +0100 From: Andrew Jones To: Conor Dooley Cc: Atish Patra , Inochi Amaoto , Qingfang Deng , Paul Walmsley , Palmer Dabbelt , Albert Ou , Atish Patra , Anup Patel , Will Deacon , Mark Rutland , Conor Dooley , Heiko Stuebner , Guo Ren , 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> <20240312-evil-resource-66370b68b9b4@spud> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240319-worry-video-66589b3ed8ae@spud> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240319_063925_334277_0BD6CCDA X-CRM114-Status: GOOD ( 41.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel