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

[Jin Ma]

> 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'?

> (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