From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by sourceware.org (Postfix) with ESMTPS id 0FA193858406 for ; Wed, 2 Mar 2022 04:34:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0FA193858406 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-vs1-xe2e.google.com with SMTP id e5so556614vsg.12 for ; Tue, 01 Mar 2022 20:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CrOINT7yZBVRMdUcfnC/Dv8Jz8DC0LH2ouzKEFpa/f8=; b=LX4C+tXVtxJb7FrZXumsg8314RzJApWhdQ5rYmPdrahDTNECbkb0H4VoqyhM6bRIgC A6vmsnBlT053iAbODRGfU5UaIuG8Hh4liBQgAisMK1bANTg32twBiHFLLKoxBCjaEkOp SEiuO/asXzqZk7oToaeGc0DgAnKnHG7FF6SPEqsc3oQzltok7EGE9l079kNIswlZqb5m WWUIQjqr0KijD5ewdo6n1YlR1W/yHeUkCZTrTGNyfMEYIatE6UjDij6O3julQLXTbrJr xP3BE7NlcbKX5OCTT04UOZ6fCcJJOhd2g3Zk02Yj7bZq1GuWH2bSLXuSLDSBNKcPpTuY KZKA== 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=CrOINT7yZBVRMdUcfnC/Dv8Jz8DC0LH2ouzKEFpa/f8=; b=U/DsFHmgg2/zAu5CU6xF7TXY2tbuvd4pD8+aDxG9qVR/+hWlcAlSanGdXoQ5WKNn/2 TinVBbrcN6uqTsDAtezb60aKG+3QnB51oyRyUUAuAyzzOsk4FwIJi1qC/a6veupwdDPG b4SABhqd8Rx9LEFufH/aLnwoPxoFHR7HQ8cMlXh2F183KpLOGRmLY5a/CLcMNr2fT3iR wD9U8cQXNtIYfOuiAYlj3aEiyNMKuVhtJWvJsCG8Po7Ia/bscgYHho5s6oK7jRiqx7MP pbc+Z9ItmjApCrb0ejhQx2NoRb3PE4gAv5EzwjFQxE+tRC6rHrVKn5xb0VrCbFRlSI6a v5mA== X-Gm-Message-State: AOAM531/Fj87RSLcjSB96V6socUyngICsFaQo4GHaIJ3OHusZTz0Smev lRZF9XLXven5aGN194vDx4Z8KYKFNEm4llpvdOoxsTwi/49WwA== X-Google-Smtp-Source: ABdhPJwt7DpTytMko0F5Z7zt7HgEcudoTKN8XhmfeEKGx05D5k1c508IQOMGztnto2MFUhlfi/jbKyrLLmwy62u3Nx8= X-Received: by 2002:a67:ad01:0:b0:31e:c3a4:9401 with SMTP id t1-20020a67ad01000000b0031ec3a49401mr552816vsl.83.1646195680455; Tue, 01 Mar 2022 20:34:40 -0800 (PST) MIME-Version: 1.0 References: <216cabba-5600-9e57-4c0b-b97dda951d7c@irq.a4lg.com> In-Reply-To: <216cabba-5600-9e57-4c0b-b97dda951d7c@irq.a4lg.com> From: Nelson Chu Date: Wed, 2 Mar 2022 12:34:29 +0800 Message-ID: Subject: Re: [PATCH 1/3] RISC-V: Add 'Smstateen' extension and its CSRs To: Tsukasa OI Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 04:34:42 -0000 On Fri, Feb 25, 2022 at 6:51 PM Tsukasa OI wrote: > > On 2022/02/25 15:32, Nelson Chu wrote: > > > > The privileged spec doesn't define these CSRs, they are defined and > > controlled by smstaeen extension. So I think the defined and aborted > > versions of these DECLARE_CSR should be PRIV_SPEC_CLASS_NONE, just > > like other unprivileged CSRs did. In the future, they should be > > controlled by smstaeen extension versions, but for now we don't need > > to care about this. > > > > Thanks > > Nelson > > > >> /* Dropped CSRs. */ > >> DECLARE_CSR(mbase, CSR_MBASE, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9P1, PRIV_SPEC_CLASS_1P10) > >> DECLARE_CSR(mbound, CSR_MBOUND, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9P1, PRIV_SPEC_CLASS_1P10) > >> -- > >> 2.32.0 > >> > > > > 'Sscofpmf' patch (PATCH 2/3) is modified as per your advise. > > For the rest, I noticed that there are hypervisor-related CSRs. > > For consistency with CSR_CLASS_I CSRs, I think hypervisor-related CSRs > should be masked with privileged architecture version 1.12. However, if > need_check_version == true (gas/config/tc-riscv.c) for specific CSR > class, there's no option to set PRIV_SPEC_CLASS_NONE because it would > just mean "not supported in any version". > > Separating CSR classes (H/non-H) might be an option. However, I felt > this is "too much". > > > Option A: Set minimum privileged specification to 1.9.1 for non-H CSRs > Option B: Disable version checking on certain conditions > > [Option A] > > How about this? > > - For 'Sscofpmf' (with no hypervisor-related CSRs), > use PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE > with need_check_version = false (as you recommended). > - For 'Smstateen' and 'Sstc' (with some hypervisor-related CSRs), > need_check_version = true and... > - Use PRIV_SPEC_CLASS_1P12, PRIV_SPEC_CLASS_DRAFT > for hypervisor-related CSRs > (mask with both given extension and Privileged version 1.12) > - Use PRIV_SPEC_CLASS_1P9P1, PRIV_SPEC_CLASS_DRAFT > for other CSRs > (much like unprivileged counter CSRs like `cycle') > > That means my 'Smstateen' patch (PATCH 1/3) will not be modified. > On the other hand, 'Sstc' patch (PATCH 3/3) will be (relax minimum > privileged version from 1.11 to 1.9.1 [minimum supported]). > > [Option B] > > Another option is to disable version checking if both define_version and > abort_version are PRIV_SPEC_CLASS_NONE (or more simply, if > define_version is PRIV_SPEC_CLASS_NONE). With current design, that > would remove `need_check_version' variable too. I have heard that we will have extension names of supervisor, machine and hypervisor mode in the future. So the CSRs will be controlled by the corresponding extension names with different versions. The PRIV_SPEC_CLASS_ will be replaced with the version of extensions, and the privileged spec versions will no longer be useful. Therefore, I had suggested we just set both define_version and abort_version to PRIV_SPEC_CLASS_NONE. The hypervisor CSRs will be controlled by the "h" extension if the ISA spec is updated, so it isn't worth spending so much time to discuss these similar issues, unless there are other new proposals in the future. Thanks Nelson > TBH, I see both options look equally good but have their cons. > > I would like to hear everyone else's (including your) thoughts. > > > Thanks, > Tsukasa