Re: [PATCH 4/6] riscv: hwprobe: Report Supm only when available

[Guodong Xu <guodong.xu@oss.qualcomm.com>]

Hi Radim,

On Tue, 6 Oct 2026 09:53:01 +0200, Radim Krcmar wrote:
> The RISC-V ISA defines Supm as
>
>   "An extension that indicates that there is pointer-masking support
>   available in user mode, with some facility provided in the application
>   execution environment to control pointer masking."
>
> Our facility always returns -EINVAL unless Supm support is configured,
> the pointer masking ISA extension is globally present, and the user-mode
> is running in 64-bit mode.
>
> Hiding Supm in compat tasks would add complexity that doesn't seem
> justified as 32-bit code has no reason to look at Supm anyway.
> Reporting based on the a global sysctl toggle isn't done.
>
> Do not report Supm when some harts lack the extension, because it's not
> available on any hart in that case.
>
> (Reporting Supm when only PMLEN=0 is supported isn't great, but doesn't
>  violate the text of the extension and we ought to have Supm7 and Supm16
>  extensions if we care about precision.)

Since the kernel already knows whether that is the case, could this
block use riscv_have_user_pmlen() instead (55458c7347a3 "riscv: Add a
getter for user PMLEN support")? It exposes the have_user_pmlen_* flags
that set_tagged_addr_ctrl() consults, so hwprobe would report Supm only
when the prctl can actually enable a non-zero PMLEN:

	/* PMM=0 is "disabled"; Supm is usable only with a non-zero PMLEN. */
	if (riscv_have_user_pmlen(7) || riscv_have_user_pmlen(16))
		pair->value |= RISCV_HWPROBE_EXT_SUPM;

That also replaces both tests in the block above.
1) IS_ENABLED(CONFIG_RISCV_ISA_SUPM) is covered because the getter is a
static inline returning false when the option is off.
2) riscv_isa_extension_available(NULL, SUPM) is covered because
tagged_addr_init() returns before probing PMLEN unless Supm is present on
every hart, so both flags stay false.

7 and 16 are the only PMLEN values the current standard defines (one PMM
encoding is reserved for future values).

The RVA23 profile v1.0 requires "Supm: Pointer masking, with the
execution environment providing a means to select PMLEN=0 and PMLEN=7 at
minimum", and senvcfg.PMM=0 is defined as "Pointer masking is disabled
(PMLEN = 0)". That is why the rva23u64 base behavior key in my series [1]
checks riscv_have_user_pmlen(7), and v9 will keep that. But for
hwprobe's own Supm bit the getter seems the better fit than waiting for
Supm7/Supm16.

Guodong

[1] https://lore.kernel.org/linux-riscv/20260920-rva23u64-hwprobe-v2-v8-11-5f14bc5c23d3@oss.qualcomm.com/