Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Samuel Holland <samuel.holland@sifive.com>]

Hi all,

(Also replied to the v1 thread:
https://lore.kernel.org/linux-riscv/9504b2f6-12f5-46c2-ac74-826dba3fb530@sifive.com/)

On 2025-12-31 6:08 PM, Conor Dooley wrote:
>> Should supm be handled in the same way? Add it to the device-tree of
>> RVA23U64 devices. If a kernel does not support pointer masking in user
>> space, hide the extension in cpufeature.c.
> 
> Perhaps.
> Samuel opted not to add supm to dt when he introduced the other relevant
> extensions, so the rationale from him would be helpful but I'd like to
> get more opinions on how to deal with supm specifically. supm doesn't
> really describe hardware capability, since the privilege specific
> instructions are what does that, which makes me question if it should be
> in dt at all. On the other hand, it could be argued that supm describes
> a combination of hardware capability at the dt consumer's privilege level
> and is valid on that basis. Some wording like Zkr will probably be needed,
> specifically mentioning that having supm in the dt means that corresponding
> version sxnpm for the privilege level that the devicetree is provided to
> is supported.

Supm describes a combination of the hardware capability (Smnpm or Ssnpm), the
consumer's privilege level (U), and the software at the next higher privilege
level (M or S).

If the DT is targeting U-mode, then I can see a case for adding Supm to the DT
either at runtime or based on the known capabilities of the
next-higher-privilege-mode software. So it could make sense to add a binding for
Supm. But we still shouldn't add Supm to this particular DT, because 1) this DT
is not targeting U-mode, and 2) this DT is not bound to a particular version of
S-mode software.

> Either way, we are going to need something in cpufeature.c to imply
> supm so that it appears to userspace if the privilege specific extension
> is detected and supm is enabled in the kernel. The kernel already does
> the implication internally it just isn't reported as an extension to
> userspace IIRC.
> If we permit supm in dt, we're also going to have to turn supm off if
> the Kconfig option is disabled, but that's relatively little effort
> since it mostly (or maybe entirely) reuses code from implying supm.

It's currently exposed to hwprobe() but not in /proc/cpuinfo. This was based on
my understanding that hwprobe() was the right way to check for availability of
extensions. I'm okay with adding it to /proc/cpuinfo if there's value in doing
so, but I would recommend that the extension in cpufeature.c is _not_ parsed
from the DT and only enabled synthetically.

Regards,
Samuel