public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Nelson Chu <nelson.chu@sifive.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 1/3] RISC-V: Add 'Smstateen' extension and its CSRs
Date: Fri, 25 Feb 2022 19:51:03 +0900	[thread overview]
Message-ID: <216cabba-5600-9e57-4c0b-b97dda951d7c@irq.a4lg.com> (raw)
In-Reply-To: <CAJYME4FANNdPAenpBS7ROWa1T=1VETNcbu5B28uEK2ACbMbrUQ@mail.gmail.com>

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.


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

  parent reply	other threads:[~2022-02-25 10:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 10:59 [PATCH 0/6] RISC-V: Add Privileged Arch 1.12 and More CSRs Tsukasa OI
2022-01-11 10:59 ` [PATCH 1/6] RISC-V: Reorganize testcases for CFI directives Tsukasa OI
2022-02-23  6:58   ` Nelson Chu
2022-01-11 10:59 ` [PATCH 2/6] RISC-V: Add Privileged Architecture 1.12 CSRs Tsukasa OI
2022-02-23  6:58   ` Nelson Chu
2022-02-24  2:35     ` Tsukasa OI
2022-02-24  6:05       ` Nelson Chu
2022-01-11 10:59 ` [PATCH 3/6] RISC-V: Add Privileged Arch 1.12 CSR testcases Tsukasa OI
2022-02-23  6:58   ` Nelson Chu
2022-01-11 10:59 ` [PATCH 4/6] RISC-V: Add 'Smstateen' extension and its CSRs Tsukasa OI
2022-01-11 10:59 ` [PATCH 5/6] RISC-V: Add 'Sscofpmf' extension with " Tsukasa OI
2022-01-11 10:59 ` [PATCH 6/6] RISC-V: Add 'Sstc' extension and " Tsukasa OI
2022-02-24 12:10 ` [PATCH 0/3] RISC-V: Add CSRs for several supervisor extensions Tsukasa OI
2022-02-24 12:10   ` [PATCH 1/3] RISC-V: Add 'Smstateen' extension and its CSRs Tsukasa OI
2022-02-25  6:32     ` Nelson Chu
2022-02-25  6:35       ` Tsukasa OI
2022-02-25 10:51       ` Tsukasa OI [this message]
2022-03-02  4:34         ` Nelson Chu
2022-02-24 12:10   ` [PATCH 2/3] RISC-V: Add 'Sscofpmf' extension with " Tsukasa OI
2022-02-24 12:10   ` [PATCH 3/3] RISC-V: Add 'Sstc' extension and " Tsukasa OI
2022-05-24  9:35   ` [PATCH v2 0/3] RISC-V: Add CSRs for several supervisor extensions Tsukasa OI
2022-05-24  9:35     ` [PATCH v2 1/3] RISC-V: Add 'Smstateen' extension and its CSRs Tsukasa OI
2022-05-24  9:35     ` [PATCH v2 2/3] RISC-V: Add 'Sscofpmf' extension with " Tsukasa OI
2022-05-24  9:35     ` [PATCH v2 3/3] RISC-V: Add 'Sstc' extension and " Tsukasa OI
2022-06-24  2:51     ` [PATCH v3 0/4] RISC-V: Add CSRs for several supervisor extensions Tsukasa OI
2022-06-24  2:51       ` [PATCH v3 1/4] RISC-V: Add new CSR feature gate handling (RV32,H) Tsukasa OI
2022-06-24  2:51       ` [PATCH v3 2/4] RISC-V: Add 'Smstateen' extension and its CSRs Tsukasa OI
2022-06-24  2:51       ` [PATCH v3 3/4] RISC-V: Add 'Sscofpmf' extension with " Tsukasa OI
2022-06-24  2:51       ` [PATCH v3 4/4] RISC-V: Add 'Sstc' extension and " Tsukasa OI
2022-06-28  1:40       ` [PATCH v3 0/4] RISC-V: Add CSRs for several supervisor extensions Nelson Chu
2022-06-28  5:33         ` Tsukasa OI
2022-06-28  6:56           ` Nelson Chu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=216cabba-5600-9e57-4c0b-b97dda951d7c@irq.a4lg.com \
    --to=research_trasio@irq.a4lg.com \
    --cc=binutils@sourceware.org \
    --cc=nelson.chu@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).