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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5AEFC433F5 for ; Thu, 30 Sep 2021 17:38:25 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DC92B613A0 for ; Thu, 30 Sep 2021 17:38:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DC92B613A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=riscv.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 64C0C80F12; Thu, 30 Sep 2021 19:38:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=riscv.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=riscv-org.20210112.gappssmtp.com header.i=@riscv-org.20210112.gappssmtp.com header.b="PvVYSjiJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E7DFB80F3B; Thu, 30 Sep 2021 19:38:19 +0200 (CEST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 09C86802A1 for ; Thu, 30 Sep 2021 19:38:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=riscv.org Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=markhimelstein@riscv.org Received: by mail-vs1-xe32.google.com with SMTP id z22so6680013vsp.1 for ; Thu, 30 Sep 2021 10:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscv-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hK+YIhWEc0hniYw7IaMnidd28G2Ey7XtO/0YfNWYfYM=; b=PvVYSjiJCwqfejF3MT7krukOFIIpGbW0B6rb6NeKRyVZRrBLT1FZ71WQNG0HaCHJb9 X8F0bLVXBEyuu/QEW2NxjBX7Ly2jSsXxgnHlXeaOWAXVoqRUqP5XFFllTbc8NUDh9n+E 0VGq1vjlwfidvw83r3h6K9lbKIsNYhHLIGBF4ZpUO0PILiSiycR3qeOAiPzoYw1NMeqk JTvAP8CXaCADP8eL7nCRDBZDTVL0cdoJhrZrxA2NnN4hl0NdEV2vApnNhsIMFDaM5GSa RysFAyqarIHBeG90ySrSmGzsq83i7dTKtbFokEaSslpHZiCcnWWF7S775nu4EC8XYI9m jDpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hK+YIhWEc0hniYw7IaMnidd28G2Ey7XtO/0YfNWYfYM=; b=aJ+j8QYqgBtEVqi3D3FSGofGIecdQR7YlhZD2UeEXTNlKgkRc32WWwf3mtpJcnYCsF 5hRsj18a3n3g3lRtr1gMEn8FJrvNf/5/kCfvbIg5H/wqzB0OEKUK6/W83OY3NlzAJUWU O94yGSNDxj1WE3aUOq51zAdGD1wTKWmxVG8C1H6UtlVyQ36USmtVpEVBUvmG3sfHzG1O oJngKUoAz0UFPJgKa4K20UK5jn5AdLxqDT+h6gE86goJUzuRwsvq9Ns6heRvXtb/CigA 6Bd+yghyAFp8f+EekHyiP0p8i2TJZBgBYgjBJd2qWXlklz8xs/0Ob3OKTXlCaiUxHYgV gksQ== X-Gm-Message-State: AOAM532968cWgkeqX3WgzPo6odzthNI+apWKRhNhilqlg6bU7keDoK7O psFg26s2P10gLhaOFSD21nOrPH/X/T2lcuYg7G+9rQ== X-Google-Smtp-Source: ABdhPJwasEEnaJQYtsZd7sXygTvPl3pSPqgOj4EfSQtXiI+oS7Hx/iclF7ghQPG1+Nhc4SmXUum5c99S8/D73pkJt+s= X-Received: by 2002:a67:e30a:: with SMTP id j10mr618433vsf.58.1633023492649; Thu, 30 Sep 2021 10:38:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Himelstein Date: Thu, 30 Sep 2021 10:38:02 -0700 Message-ID: Subject: Re: Status of the various RISC-V specification and policy To: Palmer Dabbelt Cc: Atish Patra , linux-riscv@lists.infradead.org, u-boot@lists.denx.de, al stone , Paolo Bonzini , Christoph Hellwig , Andrew Jones , xypron.glpk@gmx.de, Fu Wei , Paul Walmsley , Kumar Sankaran , Philipp Tomsich , Anup Patel , Stephano Cetola Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean The following is the extension lifecycle. It includes the official names going forward for each phase. We are trying to resolve any confusion naming and numbering and are still in progress of this evolution: https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZP= fctE4mKk/edit?usp=3Dsharing Again, if we can improve anything to make it clearer or if we got something wrong, please let us know. Mark On Thu, Sep 30, 2021 at 10:30 AM Palmer Dabbelt wrote: > On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@riscv.org wrote: > > Palmer, > > > > > > > > Thank you for your input. > > > > > > > > Our strong intention is to not change specs once frozen. I speak for th= e > > committees here and say that, in our opinion, declaring something froze= n > > sets a very high bar for making any changes and is sufficient to allow > code > > supporting an extension to be upstreamed. Of course if an unexpected an= d > > significant issue is discovered during the public review that absolutel= y > > must be addressed and cannot be deferred to a future extension (where t= he > > cost of not addressing the issue exceeds the cost of addressing it. for > > example introduces security vulnerabilities), then we will do so, as > anyone > > should expect from a public review. > > > > > > > > We do not have versions of extensions. If an extension has a problem on= ce > > ratified, we will issue errata. All implementers have to publish the > errata > > if they use branding. We may release a new extension with the bulk of t= he > > original extension plus the errata fix at some future date. > > This is probably at the core of my confusion here. > > At the preface of the user ISA there is a table with the headings > "Extension", "Version", and "Frozen"; contains a list of letters that > look like extension name; and contains a list of numbers that look like > versions of those extensions. > > That nomenclature seems to carry on to some more recent specifications. > For example the first page of > > https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec= -1.0.pdf > (tagged 11 days ago) is > > RISC-V "V" Vector Extension > Version 1.0 > > I'm happy to answer the rest of the questions here, but I think trying > to get on the same page about what is versioned and is proabbly the > first step because that's a pretty key component of my worries. > > > New extensions reserve the right to be incompatible with existing > > extensions but our philosophy is very much to minimize that and only > allow > > the rare well-justified exceptions. Reasons may include errata, securi= ty > > issues discovered, or new functionality we need to add that justifies > > creating an incompatibility, etc. > > > > What specifically do you see as an issue? What are you blocked on by ou= r > > conventions? We need specific details to resolve any issues. Right now,= I > > don't feel I have enough information from you. > > > > > > > > Thanks > > > > Mark > > > > > > > > P.S. We had some situations in the past, in part due to vendors not > waiting > > for the specification processes to conclude, where implementers > implemented > > non-confoming chips either with vendor-specific extensions using reserv= ed > > opcodes and state, or implementing early drafts of standards-track > > proposals in the development state (will likely change). This is in the > > past and resolved. Anyone implementing non-standard extensions must > > advertise them as such and make it clear that these are not standard > RISC-V > > extensions: this should make it clear for upstream projects that they > will > > be dealing with the respective vendors for support and maintenance, and > > that any code implementing support for these extensions will be differe= nt > > from what covers the respective standard extensions. Whether upstream > > projects accept such changes, and what conditions they stipulate for > > acceptance of these changes, are beyond the control of RISC-V. We also= , > as > > I have described to you many times, have instituted mandatory standards > > specification states for the front page of each specification to ensure > > clarity (any divergence from this is a bug and we work to fix these > > quickly). > > > > > > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt > wrote: > > > >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@riscv.org > wrote: > >> > the words in this document : > >> > > >> > > >> > https://wiki.riscv.org/plugins/servlet/mobile?contentId=3D13098230#conten= t/view/13098230 > >> > > >> > make it very clear when changes are allowed or not and likely or not= . > >> > > >> > if you think the verbiage is somehow ambiguous please help us make i= t > >> better. > >> > >> I'm not really worried about changes, I'm worried about a committment = to > >> future compatibility. When we take code into the kernel (and most oth= er > >> core systems projects) we're taking on the burden of supporting (until > >> someone can prove there are no more users), which is very difficult to > >> do when the ISA changes in an incompatible fashion. The whole point o= f > >> agreeing on the frozen thing was that it gave us a committment from th= e > >> specifcation authors that the future ISA would be compatible with th > >> frozen extensions. > >> > >> We're already in this spot with the V extension and the whole stable > >> thing, this definitaion of frozen looks very much like what was has le= d > >> to the issues there. Saying the spec won't change really isn't > >> meaningful, it's saying future specs will be compatible that's > >> important. Nothing in this whole rule touches on compatibility, and I > >> really don't want to end up in a bigger mess than we're already in. > >> > >> (Also: some PGE subcontractor drove a crane into my house, so things a= re > >> a bit chaotic on my end. If you have that list of what's officially > >> frozen, can you send it out? I'll try to take a look ASAP, as then I > >> can at least focus the discussion on what's relevant right now.) > >> > >> > > >> > Mark > >> > -------- > >> > sent from a mobile device. please forgive any typos. > >> > > >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt > wrote: > >> >> > >> >> =EF=BB=BFOn Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@atishpatr= a.org > wrote: > >> >>> Hi All, > >> >>> Please find the below email from Stephano about the freeze > >> announcement for > >> >>> various RISC-V specifications that will be part of privilege > >> specification > >> >>> v1.12. > >> >>> All the review discussions are happening in the isa-dev mailing > list. > >> The > >> >>> review period will be open for 45 days ending Sunday October 31, > 2021. > >> >>> > >> >>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO > >> extensions > >> >>> are frozen now. *This will help us merge some patches that have be= en > >> >>> present in the mailing list for a while. > >> >>> > >> >>> Here are the ratification policy and extension life cycle document= s > >> present > >> >>> in the public. If you have any questions regarding this, please > check > >> with > >> >>> Mark/Stephano (cc'd). > >> >>> > >> >>> Ratification policy: > >> >>> > >> > https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_= tpViwM/edit > >> >>> > >> >>> Extension life cycle: > >> >>> > >> > https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7= ZPfctE4mKk/edit#slide=3Did.p1 > >> >> > >> >> I'm still buried after Plumbers, but one of the bits on my TODO lis= t > >> was to look throught the new definitions for frozen and stable. > Nothing in > >> this extension life cycle talks about the point at which compatibility > will > >> be maintained, which was really the central point behind frozen before= . > >> >> > >> >> Are there more concrete definitions somewhere? > >> >