[PATCH v6 08/21] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing

[Atish Patra]

On 6/8/26 11:14 PM, sashiko-bot at kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Supervisor extension Ssccfg incorrectly depends on Machine extension Smcdeleg, breaking virtualization.
> - [Medium] The Smcdeleg extension validation incorrectly checks for the Supervisor-level CSR indirection extension (SSCSRIND) instead of the Machine-level one (SMCSRIND).
> --
>
> commit 53e139b078ec8b41f58b09bfd3d37e7132a15d45
> Author: Atish Patra <atishp at rivosinc.com>
>
>      RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
>
> This commit adds definitions and parsing logic for the RISC-V Ssccfg
> and Smcdeleg ISA extensions. It introduces validation functions for
> both extensions and adds them to the riscv_isa_ext array.

+linux-riscv

Sashiko probably has a bug where it did not determine correctly which 
mailing lists to cc and left linux-riscv.

>> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>> index 1452521d740a6..1fe647e035157 100644
>> --- a/arch/riscv/kernel/cpufeature.c
>> +++ b/arch/riscv/kernel/cpufeature.c
>> @@ -330,6 +330,27 @@ static const unsigned int riscv_a_exts[] = {
>>   	RISCV_ISA_EXT_ZKNE,	\
>>   	RISCV_ISA_EXT_ZKNH
>>   
>> +static int riscv_ext_smcdeleg_validate(const struct riscv_isa_ext_data *data,
>> +				       const unsigned long *isa_bitmap)
>> +{
>> +	if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SSCSRIND) &&
>                                                          ^^^^^^^^^^^^^^^^^^^^^^
> [Severity: Medium]
> Since Smcdeleg is a Machine-mode extension, shouldn't its validation depend on
> the Machine-level CSR indirect access extension (SMCSRIND) rather than the
> Supervisor-level extension (SSCSRIND)?

The reason for this dependency is that both Smcdeleg and SSCSRIND are 
required for using counter
delegation usage in S-mode.


> If the kernel runs in M-mode, or on hardware that implements SMCSRIND but not
> SSCSRIND, this validation might incorrectly fail.
Not a valid use.
>> +	    __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZIHPM) &&
>> +	    __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZICNTR))
>> +		return 0;
>> +
>> +	return -EPROBE_DEFER;
>> +}
>> +
>> +static int riscv_ext_ssccfg_validate(const struct riscv_isa_ext_data *data,
>> +				     const unsigned long *isa_bitmap)
>> +{
>> +	if (!riscv_ext_smcdeleg_validate(data, isa_bitmap) &&
>> +	    __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SMCDELEG))
> [Severity: High]
> Does this break supervisor counter delegation in virtualized environments?
>
> Smcdeleg is a Machine-mode extension, and hypervisors typically do not expose
> M-mode extensions to guest VMs. A guest kernel running in VS-mode won't see
> Smcdeleg in its ISA string, causing this validation to unconditionally fail
> and return -EPROBE_DEFER.
>
> Should Ssccfg validation only depend on S-mode visible extensions?

No. The spec is not designed that way. Counter delegation is not 
available in VS-mode.

Both comments are N/A

>> +		return 0;
>> +
>> +	return -EPROBE_DEFER;
>> +}