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 2E86CC433F5 for ; Thu, 30 Sep 2021 17:30:23 +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 03E75613A9 for ; Thu, 30 Sep 2021 17:30:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 03E75613A9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dabbelt.com 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 C9E5780F1A; Thu, 30 Sep 2021 19:30:18 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=dabbelt-com.20210112.gappssmtp.com header.i=@dabbelt-com.20210112.gappssmtp.com header.b="ACZo9c6v"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1F6F3802A1; Thu, 30 Sep 2021 19:30:17 +0200 (CEST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 AE24080F1A for ; Thu, 30 Sep 2021 19:30:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=palmer@dabbelt.com Received: by mail-ua1-x92e.google.com with SMTP id t36so4811562uad.4 for ; Thu, 30 Sep 2021 10:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=nKIZ7duxXpm1KTru1wnEl76fDcaTfnyKO/Rc139JjHk=; b=ACZo9c6vINQ9GC2hdJCBlPyUTb6aFB/QFJ+iJBgV3nqa2rmfBDhfVor8l+3IvTonwr o58bjYE50vQNb2ToS3m/O1WCdd/H1wLJXOi57JvivNvqeFG9aVKtdqX9GYj9KACXHxF6 qaYtRKQyvZnEpU9+x/q+gFnR36OMiH1uT15BQJdWrvlIc95ZFfSll023cMyQtr5i+6/4 /qT7llahLVVTDxlJjdNVi5lPZUHJ8XrZpnvXCB3PnLXllhLm31DjYsoAjMHC7PmtnCJ7 BOwhoTrliilq/5zoDLPP9RFw+mEZbGxo0bdMnqDqYaWEni7OjT6hr4vJ05xR+SlW8SMx Rnkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=nKIZ7duxXpm1KTru1wnEl76fDcaTfnyKO/Rc139JjHk=; b=6i1HdxWS6k5cv5usoI+GhoeM006SumresDxw5aMF9fzzI9cFsUTd+cSMe6yzpWUDPC 5Uh1NHqRFxmxXeet32y+mWGvcZEYq5qirI5zbnDVnnaTiXdz51uyaKo60jcupZrAa2mx ruMwVXrvRbPUkqGEp1x10pC/inLLJHlGLdyLrqDzWnitG3Ijip6gqdecqqKa1Ex2CyWO L+px2cxJ8kqiWoxPCWH8tNtAq4c34BQGtXD2NQmVQtMf1DbJJ4hANjteaoZfRYVK3Nqt VIy1jXd7FC0MlAgcDYzZa2ow6iyP7D6wgTvRCKAk/mhEgkG/E8tJ/VToPip0GnoUGTf4 qSKQ== X-Gm-Message-State: AOAM531XU4Z9o67nSQGa6j+bIDJ7lB04ekjHmTXEU+GgiCkpav0yuspk BJm5bLKP5/FkLdakaoofe3SvNA== X-Google-Smtp-Source: ABdhPJyj+VdtO4F5N86eQpJerrPc4bLRdExtwZajx8xSxw1WpWOySGNpljia5QUSk2VUCtP6KD+PNg== X-Received: by 2002:ab0:3d99:: with SMTP id l25mr7061936uac.83.1633023009221; Thu, 30 Sep 2021 10:30:09 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id k17sm1937880vke.53.2021.09.30.10.30.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 10:30:08 -0700 (PDT) Date: Thu, 30 Sep 2021 10:30:08 -0700 (PDT) X-Google-Original-Date: Thu, 30 Sep 2021 10:30:04 PDT (-0700) Subject: Re: Status of the various RISC-V specification and policy In-Reply-To: CC: atishp@atishpatra.org, linux-riscv@lists.infradead.org, u-boot@lists.denx.de, ahs3@redhat.com, pbonzini@redhat.com, Christoph Hellwig , drjones@redhat.com, xypron.glpk@gmx.de, tekkamanninja@gmail.com, Paul Walmsley , ksankaran@ventanamicro.com, ptomsich@ventanamicro.com, anup@brainfault.org, stephano@riscv.org From: Palmer Dabbelt To: markhimelstein@riscv.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 the > committees here and say that, in our opinion, declaring something frozen > 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 and > significant issue is discovered during the public review that absolutely > must be addressed and cannot be deferred to a future extension (where the > 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 once > 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 the > 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, security > 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 our > 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 reserved > 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 different > 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=13098230#content/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 it >> 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 other >> 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 of >> agreeing on the frozen thing was that it gave us a committment from the >> 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 led >> 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 are >> 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: >> >> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@atishpatra.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 been >> >>> present in the mailing list for a while. >> >>> >> >>> Here are the ratification policy and extension life cycle documents >> 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/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 >> >> >> >> I'm still buried after Plumbers, but one of the bits on my TODO list >> 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? >>