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 12EC7C77B61 for ; Thu, 27 Apr 2023 17:16:23 +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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GwULcKGyoXA78i1+Nb+byZnQkL5zHgghDQLyIjy2Sy4=; b=n2mSy8Dj9Vt/gK JeDTaaaqU4hDXhfgMCBaW/Zer2C3LrkNQ+BTBV5P61jIIsEjh0xtWVyyxDsr4sGmN+d2fJMn8kldF nZ6G6CFEvCAyNV9tnV5THCxPJ2C2wxloUEriGUNIeh9ijNVu3vnddNHtVPKnuR2DMHzNK+TPPd9uP Rff6aqix3spqiNVuashQPnGiCr7kmgZvsAIRwZiNQfS3yVUHqsL46//ZfutTjS1SLpdNUxw+NkKs/ eNxnfM594OCEUnbisoXy51io5A3onDFVTWPuecWiGx4WxN2PpS9xhod+fg0jlZ1RP0CGeD0O/HG8y 6vEUGrB5WqxmUKsNTbww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ps5E4-0074xZ-0z; Thu, 27 Apr 2023 17:16:12 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ps5E1-0074vu-1q for linux-riscv@lists.infradead.org; Thu, 27 Apr 2023 17:16:11 +0000 Received: from ip4d1634d3.dynamic.kabel-deutschland.de ([77.22.52.211] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ps5Dr-0006cU-50; Thu, 27 Apr 2023 19:15:59 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Conor Dooley Cc: palmer@dabbelt.com, linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, kito.cheng@sifive.com, jrtc27@jrtc27.com, matthias.bgg@gmail.com, heinrich.schuchardt@canonical.com, greentime.hu@sifive.com, nick.knight@sifive.com, christoph.muellner@vrull.eu, philipp.tomsich@vrull.eu, richard.henderson@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] RISC-V: add support for vendor-extensions via AT_BASE_PLATFORM and xthead Date: Thu, 27 Apr 2023 19:15:58 +0200 Message-ID: <5016896.Mh6RI2rZIc@diego> In-Reply-To: <20230426-spirits-ludicrous-a5d8275686e6@wendy> References: <20230424194911.264850-1-heiko.stuebner@vrull.eu> <20230424194911.264850-5-heiko.stuebner@vrull.eu> <20230426-spirits-ludicrous-a5d8275686e6@wendy> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230427_101609_609191_088267A1 X-CRM114-Status: GOOD ( 52.47 ) X-BeenThere: linux-riscv@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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org SGV5IENvbm9yLAoKQW0gTWl0dHdvY2gsIDI2LiBBcHJpbCAyMDIzLCAxNDoyOToxNiBDRVNUIHNj aHJpZWIgQ29ub3IgRG9vbGV5Ogo+IE9uIE1vbiwgQXByIDI0LCAyMDIzIGF0IDA5OjQ5OjExUE0g KzAyMDAsIEhlaWtvIFN0dWVibmVyIHdyb3RlOgo+ID4gRnJvbTogSGVpa28gU3R1ZWJuZXIgPGhl aWtvLnN0dWVibmVyQHZydWxsLmV1Pgo+ID4gCj4gPiBULUhlYWQgY29yZXMgc3VwcG9ydCBhIG51 bWJlciBvZiBvd24gSVNBIGV4dGVuc2lvbnMgdGhhdCBhbHNvIGluY2x1ZGUKPiA+IG9wdGltaXpl ZCBpbnN0cnVjdGlvbnMgd2hpY2ggY291bGQgYmVuZWZpdCB1c2Vyc3BhY2UgdG8gaW1wcm92ZQo+ ID4gcGVyZm9ybWFuY2UuCj4gPiAKPiA+IEV4dGVuc2lvbnMgc3VwcG9ydGVkIGJ5IGN1cnJlbnQg VC1IZWFkIGNvcmVzIGFyZToKPiA+ICogWFRoZWFkQmEgLSBiaXRtYW5pcHVsYXRpb24gaW5zdHJ1 Y3Rpb25zIGZvciBhZGRyZXNzIGNhbGN1bGF0aW9uCj4gPiAqIFhUaGVhZEJiIC0gY29uZGl0aW9u YWwgYmFzaWMgYml0LW1hbmlwdWxhdGlvbiBpbnN0cnVjdGlvbnMKPiA+ICogWFRoZWFkQnMgLSBp bnN0cnVjdGlvbnMgdG8gYWNjZXNzIGEgc2luZ2xlIGJpdCBpbiBhIHJlZ2lzdGVyCj4gPiAqIFhU aGVhZENtbyAtIGNhY2hlIG1hbmFnZW1lbnQgb3BlcmF0aW9ucwo+ID4gKiBYVGhlYWRDb25kTW92 IC0gY29uZGl0aW9uYWwgbW92ZSBpbnN0cnVjdGlvbnMKPiA+ICogWFRoZWFkRk1lbUlkeCAtIGlu ZGV4ZWQgbWVtb3J5IG9wZXJhdGlvbnMgZm9yIGZsb2F0aW5nLXBvaW50IHJlZ2lzdGVycwo+ID4g KiBYVGhlYWRGbXYgLSBkb3VibGUtcHJlY2lzaW9uIGZsb2F0aW5nLXBvaW50IGhpZ2gtYml0IGRh dGEgdHJhbnNtaXNzaW9uCj4gPiAgICAgICAgICAgICAgIGludHJ1Y3Rpb25zIGZvciBSVjMyCj4g PiAqIFhUaGVhZEludCAtIGluc3RydWN0aW9ucyB0byByZWR1Y2UgdGhlIGNvZGUgc2l6ZSBvZiBJ U1JzIGFuZC9vciB0aGUKPiA+ICAgICAgICAgICAgICAgaW50ZXJydXB0IGxhdGVuY2llcyB0aGF0 IGFyZSBjYXVzZWQgYnkgSVNSIGVudHJ5L2V4aXQgY29kZQo+ID4gKiBYVGhlYWRNYWMgLSBtdWx0 aXBseS1hY2N1bXVsYXRlIGluc3RydWN0aW9ucwo+ID4gKiBYVGhlYWRNZW1JZHggLSBpbmRleGVk IG1lbW9yeSBvcGVyYXRpb25zIGZvciBHUCByZWdpc3RlcnMKPiA+ICogWFRoZWFkTWVtUGFpciAt IHR3by1HUFIgbWVtb3J5IG9wZXJhdGlvbnMKPiA+ICogWFRoZWFkU3luYyAtIG11bHRpLWNvcmUg c3luY2hyb25pemF0aW9uIGluc3RydWN0aW9ucwo+ID4gCj4gPiBJbi1kZXB0aCBkZXNjcmlwdGlv bnMgb2YgdGhlc2UgZXh0ZW5zaW9ucyBjYW4gYmUgZm91bmQgb24KPiA+ICAgICBodHRwczovL2dp dGh1Yi5jb20vVC1oZWFkLVNlbWkvdGhlYWQtZXh0ZW5zaW9uLXNwZWMKPiA+IAo+ID4gU3VwcG9y dCBmb3IgdGhvc2UgZXh0ZW5zaW9ucyB3YXMgbWVyZ2VkIGludG8gdGhlIHJlbGV2YW50IHRvb2xj aGFpbnMKPiA+IHNvIHVzZXJzcGFjZSBwcm9ncmFtcyBjYW4gc2VsZWN0IG5lY2Vzc2FyeSBvcHRp bWl6YXRpb25zIHdoZW4gbmVlZGVkLgo+ID4gCj4gPiBTbyBhIG1lY2hhbmlzbSB0byB0aGUgaXNh LXN0cmluZyBnZW5lcmF0aW9uIHRvIGV4cG9ydCB2ZW5kb3ItZXh0ZW5zaW9uCj4gPiBsaXN0cyB2 aWEgdGhlIGVycmF0YSBtZWNoYW5pc20gYW5kIGltcGxlbWVudCBpdCBmb3IgVC1IZWFkIEM5eHgg Y29yZXMuCj4gPiAKPiA+IFRoaXMgZXhwb3NlcyB0aGVzZSB2ZW5kb3IgZXh0ZW5zaW9ucyB0aGVu IGJvdGggaW4gQVRfQkFTRV9QTEFURk9STQo+ID4gYW5kIC9wcm9jL2NwdWluZm8uCj4gCj4gSSdt IG5vdCBlbnRpcmVseSBzdXJlIGlmIHRoaXMgcGF0Y2ggaXMgbWVhbnQgdG8gYmUgYSBkZW1vLCBi dXQgSSBkb24ndAo+IGxpa2UgdGhlIGlkZWEgb2YgdXNpbmcgdGhlc2UgcmVnaXN0ZXJzIHRvIGRl dGVybWluZSB3aGF0IGV4dGVuc2lvbnMgYXJlCj4gcmVwb3J0ZWQuCgpJdCB0b29rIG1lIGEgd2hp bGUgdG8gZ3Jhc3AgdGhlIGFib3ZlLCBidXQgSSB0aGluayB5b3UgbWVhbiBkZXRlcm1pbmluZwpl eHRlbnNpb25zIGJhc2VkIG9uIG12ZW5kb3IgZXRjLCByaWdodD8KCgo+IHJpc2N2LGlzYSBpbiBh IGRldmljZXRyZWUgKGZvciBhcyBtdWNoIGFzIEkgbWlnaHQgZGlzbGlrZSBpdCBhdCB0aGlzCj4g cG9pbnQgaW4gdGltZSksIG9yIHRoZSBBQ1BJIGVxdWl2YWxlbnQsIHNob3VsZCBiZSB0aGUgbWVj aGFuaXNtIGZvcgo+IGVuYWJsaW5nL2Rpc2FibGluZyB0aGVzZSBraW5kcyBvZiB0aGluZ3MuCgo+ IE90aGVyd2lzZSwgd2UgYXJlIGp1c3QgZ29pbmcgdG8gZW5kIHVwIGNhdXNpbmcgcHJvYmxlbXMg Zm9yIG91cnNlbHZlcwo+IHdpdGggdmFyaW91cyBsaXN0cyBvZiB0aGlzIHRoYXQgYW5kIHRoZSBv dGhlciBleHRlbnNpb24gZm9yIGRpZmZlcmVudAo+IGNvbWJpbmF0aW9ucyBvZiBoYXJkd2FyZS4K PiBUaGUgb3BlbiBzb3VyY2UgYzkwNiBoYXMgdGhlIHNhbWUgYXJjaGlkL2ltcGlkIHRvbyByaWdo dD8gQXNzdW1pbmcgdGhpcyBpcwo+IGEgc2VyaW91cyBwcm9wb3NhbCwgaG93IHdvdWxkIHlvdSBp bnRlbmQgZGVhbGluZyB3aXRoIG1vZGlmaWVkIHZlcnNpb25zCj4gb2YgdGhvc2UgY29yZXM/Cj4g Cj4gSSBhbSBwcmV0dHkgc3VyZSB0aGF0IHlvdSBpbnRlbmRlZCB0aGlzIHRvIGJlIGEgZGVtbyB0 aG91Z2gsIHBhcnRpY3VsYXJseQo+IGdpdmVuIHRoZSB3b3JkaW5nIG9mIHRoZSBiZWxvdyBxdW90 ZSBmcm9tIHlvdXIgY292ZXIsCgp5ZWFoLCB0aGlzIG9uZSB3YXMgbW9yZSBmb2xsb3dpbmcgYSB0 cmFpbiBvZiB0aG91Z2h0LiBUaGlua2luZyBhYm91dCB0aGUKaXNzdWVzLCB0aGlzIHdhcyBtb3Jl IG9mIGFuIGFkZG9uIHRob3VnaHQsIGFzIEkgd2Fzbid0IHJlYWxseSBzdXJlIHdoaWNoCndheSB0 byBnby4KClNvIHlvdSdyZSByaWdodCwgdmVuZG9yIGlzYS1leHRlbnNpb25zIHNob3VsZCBhbHNv IGNvbWUgZnJvbSB0aGUgSVNBCnN0cmluZyBmcm9tIGZpcm13YXJlLCBzaW1pbGFyIHRvIHRoZSBi YXNlIGV4dGVuc2lvbnMuIE5vdCBiYXNlZCBvbiB0aGUKbXZlbmRvci1pZCBhbmQgZnJpZW5kcy4K CgoKPiBidXQgaW4gY2FzZSB5b3UgZGlkCj4gbm90Ogo+IAo+IE5BSyB0byB0aGlzIHdheSBvZiBz b3VyY2luZyB0aGUgaW5mb3JtYXRpb24uCj4gCj4gQW55d2F5cywgc2luY2UgeW91ciBjb3Zlcidz IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2VlbXMgcGFydGx5IGFpbWVkIGF0Cj4gbWUsIGdpdmVu IG15IGRpc2N1c3Npb24gd2l0aCBoZWFkLXRoZS1iYWxsIGxhc3Qgd2VlazoKPiAKPiA+IFRoaW5n cyB0byBzdGlsbCBjb25zaWRlcjoKPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+IFJp Z2h0IG5vdyBib3RoIGh3cHJvYmUgYW5kIHRoaXMgYXBwcm9hY2ggd2lsbCBvbmx5IHBhc3MgdGhy b3VnaAo+ID4gZXh0ZW5zaW9ucyB0aGUga2VybmVsIGFjdHVhbGx5IGtub3dzIGFib3V0IGl0c2Vs Zi4gVGhpcyBzaG91bGQgbm90Cj4gPiBuZWNlc3NhcmlseSBiZSBuZWVkZWQgKGJ1dCBjb3VsZCBi ZSBhbiBvcHRpb25hbCBmZWF0dXJlIGZvciBlLmcuIHZpcnR1YWxpemF0aW9uKS4KPiAKPiBXaGF0 IGRvIHlvdSBtZWFuIGJ5IHZpcnR1YWxpc2F0aW9uIGhlcmU/IEl0J3MgdGhlIGpvYiBvZiB0aGUg aHlwZXJ2aXNvcgo+IGV0YyB0byBtYWtlIHN1cmUgdGhhdCB3aGF0IGl0IHBhc3NlcyB0byBpdHMg Z3Vlc3QgY29udGFpbnMgb25seSB3aGF0IGl0Cj4gd2FudHMgdGhlIGd1ZXN0IHRvIHNlZSwgcmln aHQ/Cj4gSUlVQywgdGhhdCdzIGFub3RoZXIgcG9pbnQgYWdhaW5zdCBkb2luZyB3aGF0IHRoaXMg cGF0Y2ggZG9lcy4KCkkgZ3Vlc3MgSSdtIHN0aWxsIHNlZWluZyBaYmIgYW5kIGZyaWVuZHMgLSB3 aXRoIGp1c3QgY29tcHV0YXRpb25hbAppbnN0cnVjdGlvbnMgYXMgYWx3YXlzIGdvb2QgdG8gaGF2 ZS4gQnV0IEkgZ3Vlc3MgeW91J3JlIHJpZ2h0IHRoYXQgdGhlCmh5cGVydmlzb3Igc2hvdWxkIGJl IGFibGUgdG8gY29udHJvbCBpdHNlbGYgd2hpY2ggZXh0ZW5zaW9ucy4KCgo+ID4gTW9zdCBleHRl bnNpb25zIGRvbuKAmXQgaW50cm9kdWNlIG5ldyB1c2VyLW1vZGUgc3RhdGUgdGhhdCB0aGUga2Vy bmVsIG5lZWRzIHRvCj4gPiBtYW5hZ2UgKGUuZy4gbmV3IHJlZ2lzdGVycykuIEV4dGVuc2lvbiB0 aGF0IGRvIGludHJvZHVjZSBuZXcgdXNlci1tb2RlIHN0YXRlCj4gPiBhcmUgdXN1YWxseSBkaXNh YmxlZCBieSBkZWZhdWx0IGFuZCBoYXZlIHRvIGJlIGVuYWJsZWQgYnkgUyBtb2RlIG9yIE0gbW9k ZQo+ID4gKGUuZy4gRlNbMTowXSBmb3IgdGhlICtmbG9hdGluZy1wb2ludCBleHRlbnNpb24pLiBT byB0aGVyZSBzaG91bGQgbm90IGJlIGEKPiA+IHJlYXNvbiB0byBmaWx0ZXIgYW55IGV4dGVuc2lv bnMgdGhhdCBhcmUgdW5rbm93bi4KPiAKPiBJIHRoaW5rIGluIGdlbmVyYWwgdGhpcyBjYW4gYmUg c2FmZWx5IGFzc3VtZWQsIGJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzCj4gdW5yZWFzb25hYmxlIHRv IGV4cGVjdCBzb21lb25lIG1heSBtYWtlLCBmb3IgZXhhbXBsZSwgWENvbm9yR2lnYVZlY3Rvcgo+ IHRoYXQgZ2V0cyB0dXJuZWQgb24gYnkgdGhlIHNhbWUgYml0cyBhcyByZWd1bGFyIG9sZCB2ZWN0 b3IgYnV0IGhhcyBzb21lCj4gZXh0cmEgcmVnaXN0ZXJzLgo+IE5vdCBzYXlpbmcgdGhhdCBJIHRo aW5rIHRoYXQgdGhhdCBpcyBhIGdvb2QgaWRlYSwgYnV0IGl0IGlzIGEgZGlzdGluY3QKPiBwb3Nz aWJpbGl0eSB0aGF0IHRoaXMgd2lsbCBoYXBwZW4sIGFuZCBJIGRvbid0IHRoaW5rIGZvcndhcmRp bmcgaXQgdG8KPiB1c2Vyc3BhY2UgaXMgYSBnb29kIGlkZWEuCgpUaGUgdGhlYWQtdmVjdG9yICgw LjcuMSkgd291bGQgcHJvYmFibHkgZml0IHRoaXMgZGVzY3JpcHRpb24uIFRob3VnaCBpbgp0aGF0 IGNhc2UsIHVzZXJzcGFjZSBkZWZpbml0bHkgbmVlZHMgdG8ga25vdyBhYm91dCBpdCwgdG8gdXNl IGl0IDotKSAuCgpCdXQgb2YgY291cnNlIHRoaXMgc2hvdWxkIG9ubHkgYmUgZm9yd2FyZGVkIHdo ZW4gcmVsZXZhbnQgc3VwcG9ydAppcyBhdmFpbGFibGUgaW4gdGhlIGtlcm5lbC4KCgo+ID4gU28g aXQgbWlnaHQgbWFrZSBtb3JlIHNlbnNlIHRvIGp1c3QgcGFzcyB0aHJvdWdoIGEgY3VyYXRlZCBs aXN0IChjb21tb24KPiA+IHNldCkgY3JlYXRlZCBmcm9tIHRoZSBjb3JlJ3MgaXNhIHN0cmluZ3Mg YW5kIHJlbW92ZSBzdGF0ZS1oYW5kbGluZwo+ID4gZXh0ZW5zaW9ucyB3aGVuIHRoZXkgYXJlIG5v dCBlbmFibGVkIGluIHRoZSBrZXJuZWwtc2lkZSAoc29ydCBvZgo+ID4gYmxhY2tsaXN0aW5nIGV4 dGVuc2lvbnMgdGhhdCBuZWVkIGFjdHVhbCBrZXJuZWwgc3VwcG9ydCkuCj4gCj4gWWVhaCwgYXMg ZGlzY3Vzc2VkIHdpdGggQ2hyaXN0b3BoIHRoZSBvdGhlciBkYXkgSSBkb24ndCB0aGluayB3ZSBj YW4KPiByZWFsbHkgYXZvaWQgc3VjaCBhIGJsYWNrbGlzdC4gSSBkb24ndCB0aGluayBpdCdkIHJl cXVpcmUgYW55IHNvcnQgb2YKPiB2ZW5kb3Igc3BlY2lmaWMgaGFuZGxpbmcsIHNpbmNlLCBhcyB5 b3UgcG9pbnQgb3V0LCBhIHZlbmRvciBtYXkgd2VsbAo+IGltcGxlbWVudCBleHRlbnNpb25zIHRo YXQgd2VyZSBjcmVhdGVkIGJ5IG90aGVyIGNvbXBhbmllcy4KPiAKPiBJdCdzIGVhc3ksIHJpZ2h0 Pz8gIkp1c3QiIHBhcnNlIHRoZSBkdCwgdG9rZW5pc2UgdGhlIGV4dGVuc2lvbnMgJiBkZWxldGUK PiB3aGF0ZXZlciBpcyBpbiB0aGUgYmxhY2tsaXN0LCByaWdodD8KCkFuZCB0aGVuIHJlYWxpdHkg aGFwcGVucyA7LSkKCgo+IEh5cGVyYm9sZSBhc2lkZSwgSSB0aGluayB0aGF0IGRvaW5nIHNvbWV0 aGluZyBsaWtlIHRoaXMgaW5jcmVhc2VzIHRoZQo+IG5lZWQgZm9yIGEgc3lzdGVtIGxpa2UgRXZh bidzLCBhcyB1c2Vyc3BhY2UgbWF5IG5lZWQgYSB3YXkgdG8KPiBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gd2hhdCB0aGUgaGFyZHdhcmUgaXMgY2FwYWJsZSBvZiAoYXMgcmVwb3J0ZWQgYnkKPiB0aGUg aXNhIHN0cmluZyBpbiAvcHJvYy9jcHVpbmZvIG9yIHRoZSBjb250ZW50IG9mIDMvNCkgYW5kIHdo YXQgdGhlCj4ga2VybmVsIGFjdHVhbGx5IHN1cHBvcnRzLgo+Cj4gPiBIb3dldmVyLCB0aGlzIGlz IGEgdmVyeSByZWxhdGVkLCBidXQgc3RpbGwgaW5kZXBlbmRlbnQgZGlzY3Vzc2lvbi4KPiAKPiBB eWUsIHRoaXMgZGlzY3Vzc2lvbiBhbmQgdGhlIGZpcnN0IHR3byBwYXRjaGVzIGFyZSByZWxldmFu dCB3aGV0aGVyIDMvNAo+IGlzIGFjY2VwdGVkIG9yIG5vdCBJTU8uCgpJIGd1ZXNzIEknbGwgcG9r ZSB0aGlzIHNvbWUgbW9yZSBpbiB0aGUgbWVhbnRpbWUsIHRha2luZyBpbnRvIGFjY291bnQKYWxs IHRoZSBjb21tZW50cyBmcm9tIGFib3ZlIDotKSAuCgoKVGhhbmtzCkhlaWtvCgoKCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1yaXNjdiBtYWls aW5nIGxpc3QKbGludXgtcmlzY3ZAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJpc2N2Cg== 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06612C77B61 for ; Thu, 27 Apr 2023 17:16:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244101AbjD0RQy convert rfc822-to-8bit (ORCPT ); Thu, 27 Apr 2023 13:16:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244441AbjD0RQm (ORCPT ); Thu, 27 Apr 2023 13:16:42 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C77B55A1 for ; Thu, 27 Apr 2023 10:16:20 -0700 (PDT) Received: from ip4d1634d3.dynamic.kabel-deutschland.de ([77.22.52.211] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ps5Dr-0006cU-50; Thu, 27 Apr 2023 19:15:59 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Conor Dooley Cc: palmer@dabbelt.com, linux-riscv@lists.infradead.org, paul.walmsley@sifive.com, kito.cheng@sifive.com, jrtc27@jrtc27.com, matthias.bgg@gmail.com, heinrich.schuchardt@canonical.com, greentime.hu@sifive.com, nick.knight@sifive.com, christoph.muellner@vrull.eu, philipp.tomsich@vrull.eu, richard.henderson@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] RISC-V: add support for vendor-extensions via AT_BASE_PLATFORM and xthead Date: Thu, 27 Apr 2023 19:15:58 +0200 Message-ID: <5016896.Mh6RI2rZIc@diego> In-Reply-To: <20230426-spirits-ludicrous-a5d8275686e6@wendy> References: <20230424194911.264850-1-heiko.stuebner@vrull.eu> <20230424194911.264850-5-heiko.stuebner@vrull.eu> <20230426-spirits-ludicrous-a5d8275686e6@wendy> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Conor, Am Mittwoch, 26. April 2023, 14:29:16 CEST schrieb Conor Dooley: > On Mon, Apr 24, 2023 at 09:49:11PM +0200, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > T-Head cores support a number of own ISA extensions that also include > > optimized instructions which could benefit userspace to improve > > performance. > > > > Extensions supported by current T-Head cores are: > > * XTheadBa - bitmanipulation instructions for address calculation > > * XTheadBb - conditional basic bit-manipulation instructions > > * XTheadBs - instructions to access a single bit in a register > > * XTheadCmo - cache management operations > > * XTheadCondMov - conditional move instructions > > * XTheadFMemIdx - indexed memory operations for floating-point registers > > * XTheadFmv - double-precision floating-point high-bit data transmission > > intructions for RV32 > > * XTheadInt - instructions to reduce the code size of ISRs and/or the > > interrupt latencies that are caused by ISR entry/exit code > > * XTheadMac - multiply-accumulate instructions > > * XTheadMemIdx - indexed memory operations for GP registers > > * XTheadMemPair - two-GPR memory operations > > * XTheadSync - multi-core synchronization instructions > > > > In-depth descriptions of these extensions can be found on > > https://github.com/T-head-Semi/thead-extension-spec > > > > Support for those extensions was merged into the relevant toolchains > > so userspace programs can select necessary optimizations when needed. > > > > So a mechanism to the isa-string generation to export vendor-extension > > lists via the errata mechanism and implement it for T-Head C9xx cores. > > > > This exposes these vendor extensions then both in AT_BASE_PLATFORM > > and /proc/cpuinfo. > > I'm not entirely sure if this patch is meant to be a demo, but I don't > like the idea of using these registers to determine what extensions are > reported. It took me a while to grasp the above, but I think you mean determining extensions based on mvendor etc, right? > riscv,isa in a devicetree (for as much as I might dislike it at this > point in time), or the ACPI equivalent, should be the mechanism for > enabling/disabling these kinds of things. > Otherwise, we are just going to end up causing problems for ourselves > with various lists of this that and the other extension for different > combinations of hardware. > The open source c906 has the same archid/impid too right? Assuming this is > a serious proposal, how would you intend dealing with modified versions > of those cores? > > I am pretty sure that you intended this to be a demo though, particularly > given the wording of the below quote from your cover, yeah, this one was more following a train of thought. Thinking about the issues, this was more of an addon thought, as I wasn't really sure which way to go. So you're right, vendor isa-extensions should also come from the ISA string from firmware, similar to the base extensions. Not based on the mvendor-id and friends. > but in case you did > not: > > NAK to this way of sourcing the information. > > Anyways, since your cover's considerations section seems partly aimed at > me, given my discussion with head-the-ball last week: > > > Things to still consider: > > ------------------------- > > Right now both hwprobe and this approach will only pass through > > extensions the kernel actually knows about itself. This should not > > necessarily be needed (but could be an optional feature for e.g. virtualization). > > What do you mean by virtualisation here? It's the job of the hypervisor > etc to make sure that what it passes to its guest contains only what it > wants the guest to see, right? > IIUC, that's another point against doing what this patch does. I guess I'm still seeing Zbb and friends - with just computational instructions as always good to have. But I guess you're right that the hypervisor should be able to control itself which extensions. > > Most extensions don’t introduce new user-mode state that the kernel needs to > > manage (e.g. new registers). Extension that do introduce new user-mode state > > are usually disabled by default and have to be enabled by S mode or M mode > > (e.g. FS[1:0] for the +floating-point extension). So there should not be a > > reason to filter any extensions that are unknown. > > I think in general this can be safely assumed, but I don't think it is > unreasonable to expect someone may make, for example, XConorGigaVector > that gets turned on by the same bits as regular old vector but has some > extra registers. > Not saying that I think that that is a good idea, but it is a distinct > possibility that this will happen, and I don't think forwarding it to > userspace is a good idea. The thead-vector (0.7.1) would probably fit this description. Though in that case, userspace definitly needs to know about it, to use it :-) . But of course this should only be forwarded when relevant support is available in the kernel. > > So it might make more sense to just pass through a curated list (common > > set) created from the core's isa strings and remove state-handling > > extensions when they are not enabled in the kernel-side (sort of > > blacklisting extensions that need actual kernel support). > > Yeah, as discussed with Christoph the other day I don't think we can > really avoid such a blacklist. I don't think it'd require any sort of > vendor specific handling, since, as you point out, a vendor may well > implement extensions that were created by other companies. > > It's easy, right?? "Just" parse the dt, tokenise the extensions & delete > whatever is in the blacklist, right? And then reality happens ;-) > Hyperbole aside, I think that doing something like this increases the > need for a system like Evan's, as userspace may need a way to > differentiate between what the hardware is capable of (as reported by > the isa string in /proc/cpuinfo or the content of 3/4) and what the > kernel actually supports. > > > However, this is a very related, but still independent discussion. > > Aye, this discussion and the first two patches are relevant whether 3/4 > is accepted or not IMO. I guess I'll poke this some more in the meantime, taking into account all the comments from above :-) . Thanks Heiko