From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH v4 1/1] RISC-V: Add platform property/capability extensions
Date: Mon, 31 Jul 2023 11:56:36 +0900 [thread overview]
Message-ID: <a4443ed5-1f07-1073-f1d6-d2865da69815@irq.a4lg.com> (raw)
In-Reply-To: <mhng-1edc0335-db7a-4a45-a972-ff69c3726428@palmer-ri-x1c9a>
Again, I'm not strongly object this decision but I'll note a background
before I forget again (and in July, before the thread tree in the
Binutils Archives website breaks).
My initial patch set (in 2022-11)
<https://sourceware.org/pipermail/binutils/2022-November/124155.html>
is approved by Nelson once.
<https://sourceware.org/pipermail/binutils/2022-November/124158.html>
But I decided not to commit it because I felt something in the RISC-V
Profiles specification will likely change (despite it being frozen; and
it did, 'Ssptead' was renamed to 'Svade' and 'Sscounterenw' was added).
I'm **not** going through using this approval since it's too old. But I
will appreciate if you consider this a little. As I replied earlier, I
can wait until RISC-V Profiles through "-march" is supported.
<https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/36>
Thanks,
Tsukasa
On 2023/07/26 9:47, Palmer Dabbelt wrote:
> On Tue, 25 Jul 2023 17:05:53 PDT (-0700), research_trasio@irq.a4lg.com
> wrote:
>> From: Tsukasa OI <research_trasio@irq.a4lg.com>
>>
>> RISC-V Profiles document defines number of "extensions" that indicate
>> certain platform properties/capabilities just like 'Zkt' extension
>> from the
>> RISC-V cryptography extensions.
>>
>> This commit defines 20 platform property/capability extensions as defined
>> in the RISC-V Profiles documentation.
>>
>> The only exception: 'Ssstateen' extension is defined separately
>> because it
>> defines a subset (supervisor/hypervisor view) of the 'Smstateen'
>> extension.
>>
>> This is based on the ratified version of RISC-V Profiles:
>> <https://github.com/riscv/riscv-profiles/releases/tag/v1.0>
>>
>> [Definition]
>>
>> "Main memory regions":
>> Main memory regions (in contrast to I/O or vacant memory regions)
>> with
>> both the cacheability and coherence PMAs.
>>
>> [New Unprivileged Extensions]
>>
>> 1. 'Ziccif'
>> "Main memory regions" support instruction fetch and any instruction
>> fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN)
>> are atomic.
>> 2. 'Ziccrse'
>> "Main memory regions" provide the eventual success guarantee for
>> LR/SC sequence (RsrvEventual).
>> 3. 'Ziccamoa'
>> "Main memory regions" support all currently-defined AMO operations
>> including swap, logical and arithmetic operations (AMOArithmetic).
>> 4. 'Za64rs'
>> For LR/SC instructions, reservation sets are contiguous, naturally
>> aligned and at most 64-bytes in size.
>> 5. 'Za128rs'
>> Likewise, but reservation sets are at most 128-bytes in size.
>> 6. 'Zicclsm'
>> Misaligned loads / stores to "main memory regions" are supported.
>> Those include both regular scalar and vector accesses but does not
>> include AMOs and other specialized forms of memory accesses.
>> 7. 'Zic64b'
>> Cache blocks are (exactly) 64-bytes in size and naturally aligned.
>
> IMO we want to stay away from these extensions that are just defined by
> a single phrase in the spec. We're still digging out from the first
> rounds of changed specs, trying to start supporting stuff that's not
> even been defined is going to just make for another round of headaches.
>
>> [New Privileged Extensions]
>>
>> 1. 'Svbare'
>> "satp" mode Bare is supported.
>> 2. 'Svade'
>> Page-fault exceptions are raised when a page is accessed when A
>> bit is
>> clear, or written when D bit is clear.
>> 3. 'Ssccptr'
>> "Main memory regions" support hardware page-table reads.
>> 4. 'Sstvecd'
>> "stvec" mode Direct is supported. When "stvec" mode is Direct,
>> "stvec.BASE" is capable of holding any valid 4-byte aligned address.
>> 5. 'Sstvala'
>> "stval" is always written with a nonzero value whenever possible as
>> specified in the Privileged Architecture documentation
>> (version 20211203: see section 4.1.9).
>> 6. 'Sscounterenw'
>> For any "hpmcounter" that is not read-only zero, the corresponding
>> bit
>> in "scounteren" is writable.
>> 7. 'Ssu64xl'
>> "sstatus.UXL" is capable of holding the value 0b10
>> (UXLEN==64 is supported).
>> 8. 'Shcounterenw'
>> Similar to 'Sscounterenw' but the same rule applies to "hcounteren".
>> 9. 'Shvstvala'
>> Similar to 'Sstvala' but the same rule applies to "vstval".
>> 10. 'Shtvala'
>> "htval" is written with the faulting guest physical address as
>> long as
>> permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala').
>> 11. 'Shvstvecd'
>> Similar to 'Sstvecd' but the same rule applies to "vstvec".
>> 12. 'Shvsatpa'
>> All translation modes supported in "satp" are also supported in
>> "vsatp".
>> 13. 'Shgatpa'
>> For each supported virtual memory scheme SvNN supported in "satp",
>> the
>> corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode
>> Bare
>> is also supported.
>>
>> [Implications]
>>
>> (Due to reservation set size constraints)
>> - 'Za64rs' -> 'Za128rs'
>>
>> (Due to the fact that a privileged "extension" directly refers a CSR)
>> - 'Svbare' -> 'Zicsr'
>> - 'Sstvecd' -> 'Zicsr'
>> - 'Sstvala' -> 'Zicsr'
>> - 'Sscounterenw' -> 'Zicsr'
>> - 'Ssu64xl' -> 'Zicsr'
>>
>> (Due to the fact that a privileged "extension" indirectly depends on
>> CSRs)
>> - 'Svade' -> 'Zicsr'
>>
>> (Due to the fact that a privileged "extension" is a hypervisor property)
>> - 'Shcounterenw' -> 'H'
>> - 'Shvstvala' -> 'H'
>> - 'Shtvala' -> 'H'
>> - 'Shvstvecd' -> 'H'
>> - 'Shvsatpa' -> 'H'
>> - 'Shgatpa' -> 'H'
>>
>> bfd/ChangeLog:
>>
>> * elfxx-riscv.c
>> (riscv_implicit_subsets): Add 13 implication rules.
>> Reorder 'H' for new 'Sh*' extensions.
>> (riscv_supported_std_z_ext) Add 7 property/capability extensions.
>> (riscv_supported_std_s_ext) Add 13 property/capability extensions.
>> ---
>> bfd/elfxx-riscv.c | 35 ++++++++++++++++++++++++++++++++++-
>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
>> index b43d2cfa0fab..47dede91e064 100644
>> --- a/bfd/elfxx-riscv.c
>> +++ b/bfd/elfxx-riscv.c
>> @@ -1105,7 +1105,6 @@ static struct riscv_implicit_subset
>> riscv_implicit_subsets[] =
>> {"g", "zicsr", check_implicit_always},
>> {"g", "zifencei", check_implicit_always},
>> {"m", "zmmul", check_implicit_always},
>> - {"h", "zicsr", check_implicit_always},
>> {"q", "d", check_implicit_always},
>> {"v", "d", check_implicit_always},
>> {"v", "zve64d", check_implicit_always},
>> @@ -1144,6 +1143,7 @@ static struct riscv_implicit_subset
>> riscv_implicit_subsets[] =
>> {"zhinx", "zhinxmin", check_implicit_always},
>> {"zhinxmin", "zfinx", check_implicit_always},
>> {"zfinx", "zicsr", check_implicit_always},
>> + {"za64rs", "za128rs", check_implicit_always},
>> {"zk", "zkn", check_implicit_always},
>> {"zk", "zkr", check_implicit_always},
>> {"zk", "zkt", check_implicit_always},
>> @@ -1179,10 +1179,23 @@ static struct riscv_implicit_subset
>> riscv_implicit_subsets[] =
>> {"smaia", "ssaia", check_implicit_always},
>> {"smstateen", "ssstateen", check_implicit_always},
>> {"smepmp", "zicsr", check_implicit_always},
>> + {"shcounterenw", "h", check_implicit_always},
>> + {"shgatpa", "h", check_implicit_always},
>> + {"shtvala", "h", check_implicit_always},
>> + {"shvsatpa", "h", check_implicit_always},
>> + {"shvstvala", "h", check_implicit_always},
>> + {"shvstvecd", "h", check_implicit_always},
>> + {"h", "zicsr", check_implicit_always},
>> {"ssaia", "zicsr", check_implicit_always},
>> {"sscofpmf", "zicsr", check_implicit_always},
>> + {"sscounterenw", "zicsr", check_implicit_always},
>> {"ssstateen", "zicsr", check_implicit_always},
>> {"sstc", "zicsr", check_implicit_always},
>> + {"sstvala", "zicsr", check_implicit_always},
>> + {"sstvecd", "zicsr", check_implicit_always},
>> + {"ssu64xl", "zicsr", check_implicit_always},
>> + {"svade", "zicsr", check_implicit_always},
>> + {"svbare", "zicsr", check_implicit_always},
>> {NULL, NULL, NULL}
>> };
>>
>> @@ -1240,6 +1253,11 @@ static struct riscv_supported_ext
>> riscv_supported_std_ext[] =
>>
>> static struct riscv_supported_ext riscv_supported_std_z_ext[] =
>> {
>> + {"zic64b", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"ziccamoa", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"ziccif", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"zicclsm", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"ziccrse", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"zicbom", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"zicbop", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"zicboz", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> @@ -1250,6 +1268,8 @@ static struct riscv_supported_ext
>> riscv_supported_std_z_ext[] =
>> {"zifencei", ISA_SPEC_CLASS_20190608, 2, 0, 0 },
>> {"zihintpause", ISA_SPEC_CLASS_DRAFT, 2, 0, 0 },
>> {"zmmul", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"za64rs", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"za128rs", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"zawrs", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"zfa", ISA_SPEC_CLASS_DRAFT, 0, 1, 0 },
>> {"zfh", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> @@ -1318,13 +1338,26 @@ static struct riscv_supported_ext
>> riscv_supported_std_z_ext[] =
>>
>> static struct riscv_supported_ext riscv_supported_std_s_ext[] =
>> {
>> + {"shcounterenw", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"shgatpa", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"shtvala", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"shvsatpa", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"shvstvala", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"shvstvecd", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"smaia", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"ssaia", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"ssccptr", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"sscounterenw", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"ssstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"sstvala", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"sstvecd", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"ssu64xl", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"svade", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"svbare", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>
next prev parent reply other threads:[~2023-07-31 2:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 12:26 [REVIEW ONLY 0/2] NEAR RATIFICATION RISC-V: Extensions from the RISC-V Profiles Tsukasa OI
2022-11-03 12:26 ` [REVIEW ONLY 1/2] NEAR-RATIFICATION RISC-V: Add 'Ssstateen' extension and its CSRs Tsukasa OI
2022-11-03 12:26 ` [REVIEW ONLY 2/2] NEAR-RATIFICATION RISC-V: Add platform property/capability extensions Tsukasa OI
2022-11-03 13:11 ` [REVIEW ONLY 0/2] NEAR RATIFICATION RISC-V: Extensions from the RISC-V Profiles Nelson Chu
2022-11-03 13:20 ` Tsukasa OI
2022-11-19 2:56 ` Tsukasa OI
2023-01-30 6:35 ` [PATCH v2 0/1] " Tsukasa OI
2023-01-30 6:35 ` [PATCH v2 1/1] RISC-V: Add platform property/capability extensions Tsukasa OI
2023-01-30 7:11 ` [PATCH v3 0/1] RISC-V: Extensions from the RISC-V Profiles Tsukasa OI
2023-01-30 7:11 ` [PATCH v3 1/1] RISC-V: Add platform property/capability extensions Tsukasa OI
2023-07-26 0:05 ` [PATCH v4 0/1] RISC-V: Extensions from the RISC-V Profiles Tsukasa OI
2023-07-26 0:05 ` [PATCH v4 1/1] RISC-V: Add platform property/capability extensions Tsukasa OI
2023-07-26 0:47 ` Palmer Dabbelt
2023-07-26 1:02 ` Tsukasa OI
2023-07-31 2:56 ` Tsukasa OI [this message]
2023-01-31 4:46 ` [PATCH v2 0/1] RISC-V: Extensions from the RISC-V Profiles 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=a4443ed5-1f07-1073-f1d6-d2865da69815@irq.a4lg.com \
--to=research_trasio@irq.a4lg.com \
--cc=binutils@sourceware.org \
--cc=palmer@dabbelt.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).