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 5423EC54E68 for ; Tue, 19 Mar 2024 20:11:56 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NYmx7cGhQyAzlbLq/0bt1pFLG4S8mDvtFpC0hlTMMVQ=; b=qiJGqbPOpmcAe7 szfKuij8KH/C5Ddcgiv5x5q/VdXL35gybq0/uw3fzzHjJcM0YVQlMuhZh23GHnOaMWLSTb/rnZzBn pTXSXcx4q3nOlpV/pq8o6lOT/2vYD46B3OHeiNfMIt2Yflx2FxYWTRUkzjzs9GU2B4si1b7kZqpW1 Yqpxtnd1DabMAAkLSw5BNiAj5c9gfDTLxX6YLxig2emxthGS353bl9VWNTCyyhfmTJxu1a+7+0FTF O5pwdJPb6QWEL7SeBAeVtB6deZJ37Lcmg/WOu0qFZYon75Nak5qWNRL72oUQRM725g7XSOmP77+ly o7sdbPptyWolLQkgKP7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmfoA-0000000E5Ub-2lgq; Tue, 19 Mar 2024 20:11:38 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmfo6-0000000E5Tj-2WIs for linux-arm-kernel@lists.infradead.org; Tue, 19 Mar 2024 20:11:36 +0000 Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-29c75e348afso4472820a91.2 for ; Tue, 19 Mar 2024 13:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1710879093; x=1711483893; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qxciHIs/9sZQePYO7DWCP1aPLuU+bU/1C9S6KStzprA=; b=wfvCClt+GVhcomZ2VpRmKnJi3M+5PyiCMzN8Ffj9RdjZoYV1amgegx/lXY+vcDwn+i FxADOZD4PYVhs6tPIMnqiYSKzgOwt1kKJlSrOfq+m4CiX8KN4zB2PfF9TqT5mXgdOcID 9CQ+QB2iYIEm8PdeafGKerJ/hyFvawlbgYAtP9TFTD9JEhxXkpKyeXFiXJaO1jXWnx4h zxK4trp7y4Yl57sUW64pf9EsTRE8ZKqOoD6tZeZ/R/8kQbjpKPGyy/Qq7nYKj8XIq2ys iILA1KffFASwrB7kQ300jn2FIkhRvHygBEIoDMSGHwYAXKqOEXvuC5aWXlnewz0L7yKa nogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710879093; x=1711483893; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qxciHIs/9sZQePYO7DWCP1aPLuU+bU/1C9S6KStzprA=; b=t16ZP21+p2JbGFqnH/sGBZOlMelliXEQxk8Vali7UVnKU24+KI61zDXJNGvJ1a05yb cIIKFuZrynEvZv3oTXHM1Xq9O8O4nDm3BJBBvwvD0oB1Yw/Xb/fmGvC2ntLmPu6z0jtz kFA119ZCh2+WpYvGe19oLpPZ3333i7rHYuJOih9zcDfvA8KXIaWRH1hnwxnVVqhWTV6e gkd5cKyvr9vOdLhs++UKZrtoPWocHOkGjXkMvZ06LNBJYwJA+cV64xKfXh00IAueon0h 69mYBp5wEL7oLWPsirjGvtf9fq0RNU5Oj1XBSSoTb+eGOLwJeMJS5WCzBXjPKKoZk5DQ eqDg== X-Forwarded-Encrypted: i=1; AJvYcCUCihwnPftUvYaO1x6YhOtWeSas/LeA5ilQsxgRXpnAH/j8JT4cHV7rMLdJ9LiQe2JEnpgxMDNh6OdWvNCvfvHxvBInuW4R7NK3aah/atTMDr9b70k= X-Gm-Message-State: AOJu0Ywbvu8jIOeu3R2msIGc4tWsacx0EL2J2Axd7p8hhQRw2Yuby7Zb 1dtl1Gn7ZdiFqT4ENVGbwv8phS1vI9BSDx1lAXY4yomteqqsPCtjA03u/8oACro= X-Google-Smtp-Source: AGHT+IG/SwXVCYVcyNCBXJ6NdanaXkVJumohnM+SJRldB3twx1Oobl3tnNyfK0D+fbGqcBUy6fb/3w== X-Received: by 2002:a17:90a:bd91:b0:29f:ef34:3004 with SMTP id z17-20020a17090abd9100b0029fef343004mr215196pjr.43.1710879092982; Tue, 19 Mar 2024 13:11:32 -0700 (PDT) Received: from ?IPV6:2601:647:4180:9630::546? ([2601:647:4180:9630::546]) by smtp.gmail.com with ESMTPSA id u5-20020a17090ac88500b0029df554300csm8554426pjt.24.2024.03.19.13.11.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Mar 2024 13:11:32 -0700 (PDT) Message-ID: <2b002585-eec9-40d3-95bc-e010b7def7a9@rivosinc.com> Date: Tue, 19 Mar 2024 13:11:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf: RISC-V: fix IRQ detection on T-Head C908 Content-Language: en-US To: Conor Dooley , Andrew Jones Cc: 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 References: <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> <20240319-3e72d732cbf2fcf1cb81f968@orel> <20240319-underfoot-dispense-dc30ea860e7c@spud> From: Atish Patra In-Reply-To: <20240319-underfoot-dispense-dc30ea860e7c@spud> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240319_131134_690369_0347F206 X-CRM114-Status: GOOD ( 54.07 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/19/24 08:36, Conor Dooley wrote: > On Tue, Mar 19, 2024 at 02:39:21PM +0100, Andrew Jones wrote: >> 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. > > Yah, both of these the vendor /should/ name it themselves but I don't > want some set in stone /must/ that locks someone who is not the vendor > from upstreaming. > >>>> 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, a large part of this is definitely based on intent. Or maybe > marketing rather than intent, but the two aren't all that different > as the public may not be privy to which it actually is. > > I think you're missing a factor though - when the difference is > discovered. Equating #1 and #2 is fine when that difference is known > when the platform is originally supported, but if the divergence between > what's implemented and the spec is only discovered down the line... > >>> 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. > May be we treat #1 and #3 are same. In this case, we just call it XTheadSscofpmf or something similar. The patches would look similar to what was proposed in Andes PMU v7 series in that case. > ... I think that means that having some workarounds are inescapable > really. Some sort of workaround could then be only way fix the problem > without a firmware update. That workaround might be triggered by the > m*id CSRs or it could be based on the firmware's SBI implemenation > or version IDs. > When it's something that never worked at all or was discovered early, > then ye equate the two. > >>>> 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. > > One of the reasons I keep bringing up when things were created prior to > the creation of Sscofpmf (and I guess the fact that the vendor never > claims to support Sscofpmf) is to highlight that we are not looking at > at one of these edge cases where we're only discovering that there's an > implementation issue on these CPUs that we need to work around silently. > >> 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. > > I'd be inclined to agree (although there's gonna be some exceptions as I > mention above) - but it's easy for me to say that given I want people to > use riscv,isa-extensions on the DT side which cites specific versions of > extensions that a device is compliant with. > If people have issues with riscv,isa in DT, I'm can take a bit of a "oh > it doesn't work with riscv,isa? Tough shit, that's why we made the new > properties." approach and push people into new names. > > With ACPI, I have absolutely no idea how you police any of that. The way > the code works rn is that both DT properties and ACPI share the exact > same extension "names". Obviously it doesn't need to be that way, but it > is handy. I'm kinda derailing here, but how would we map names to exact > features in ACPI land? When I last read the ACPI stuff it was very > non-specific and the kernel documentation > (Documentation/riscv/acpi.rst) cites a specific version of the ISA > manual that provides no information (and I guess never will?) about > vendor extensions. > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel