[PATCH v4 1/1] RISC-V: Add platform property/capability extensions

[Tsukasa OI]

On 2024/12/02 15:50, Jin Ma 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.
>>
>> [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'
> 
> Hi, Tsukasa
> 
> Since I am not very clear about this extension, I have some confusion
> about this
> implication. Are we upside down this? In my opinion, shouldn't we
> 'Za128rs' -> 'Za64rs'?

Hi Jin,

I am busy so that I cannot return to GNU Binutils development for a
while but luckily I found your email now so I'll explain this.

<https://github.com/riscv/riscv-profiles/blob/f2e15b5d66988a7165e9167b50ef10d2fd03b402/src/profiles.adoc>

You can see the definitions of 'Za64rs' and 'Za128rs' above.
I'll quote them here, too:

> Za128rs: Reservation sets must be contiguous, naturally aligned, and at most 128 bytes in size.
> Za64rs: Reservation sets are contiguous, naturally aligned, and a maximum of 64 bytes.

The keywords here are "at most" / "maximum".  Smaller reservation set
means stricter constraint (more fine grained control of atomic ops).

So, we can imply bigger reservation set constraint extension from the
smaller one.  Of course, satisfying the condition of the 'Za64rs'
extension is a superset of the 'Za128rs' extension, even if we account
other conditions.

Sorry for a rushed response.
Tsukasa

> 
>> (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},
> 
> Should we change this to \{"za128rs", "za64rs",   
> check_implicit_always},\ ?
> 
>>    {"zk", "zkn",        check_implicit_always},
>>    {"zk", "zkr",        check_implicit_always},
>>    {"zk", "zkt",        check_implicit_always},
> 
> BR
> Jin
>