public inbox for opensbi@lists.infradead.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <radim.krcmar@oss.qualcomm.com>
To: "James Raphael Tiovalen" <jamestiotio@gmail.com>,
	<opensbi@lists.infradead.org>
Cc: <andrew.jones@linux.dev>, <atishp@rivosinc.com>,
	"opensbi" <opensbi-bounces@lists.infradead.org>
Subject: Re: [PATCH] lib: sbi_pmu: Add FW counter index validation when reading high bits on RV64
Date: Mon, 19 Jan 2026 11:57:16 +0000	[thread overview]
Message-ID: <DFSJPWHEF293.2Z6H79QH3IDXR@oss.qualcomm.com> (raw)
In-Reply-To: <20260117125031.56031-1-jamestiotio@gmail.com>

2026-01-17T20:50:31+08:00, James Raphael Tiovalen <jamestiotio@gmail.com>:
> Currently, when we attempt to read the upper 32 bits of a firmware
> counter on RV64 or higher, we just set `sbiret.value` to 0 without
> validating the counter index. The SBI specification requires us to set
> `sbiret.error` to `SBI_ERR_INVALID_PARAM` if the counter index points to
> a hardware counter or an invalid counter. Add a validation check to
> ensure compliance with the specification on RV64 or higher.
>
> Fixes: 51951d9e9af8 ("lib: sbi_pmu: Implement sbi_pmu_counter_fw_read_hi")
> Signed-off-by: James Raphael Tiovalen <jamestiotio@gmail.com>
> ---

While the call is poorly specified and your interpretation is valid,
I think the intention is to make this function do nothing else than
return {err, 0} on RV64 as there isn't much reason to complicate the
implementation.

I think always returning {SBI_EINVAL, 0} would be even better than
the current {SBI_SUCCESS, 0}, but it doesn't matter much since
legitimate RV64 software shouldn't ever invoke the ecall.

> diff --git a/lib/sbi/sbi_pmu.c b/lib/sbi/sbi_pmu.c
> @@ -227,6 +227,14 @@ static bool pmu_ctr_idx_validate(unsigned long cbase, unsigned long cmask)
>  	return cmask && cbase + sbi_fls(cmask) < total_ctrs;
>  }

In case of disagreement with the above:

> +int sbi_pmu_is_fw_ctr_idx(uint32_t cidx)
> +{

This functions gets passed regs->a0, so cidx should be an xlen sized
type.
(I understand trying to be consistent, as sbi_pmu_ctr_fw_read has the
 same bug, but better fix related code when touching it.)

> +	if (cidx < num_hw_ctrs || cidx >= total_ctrs)
> +		return SBI_EINVAL;

Please refactor the check in sbi_pmu_ctr_fw_read, and use it instead of
adding more logic.

Thanks.

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

  reply	other threads:[~2026-01-19 11:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17 12:50 [PATCH] lib: sbi_pmu: Add FW counter index validation when reading high bits on RV64 James Raphael Tiovalen
2026-01-19 11:57 ` Radim Krčmář [this message]
2026-01-19 17:32   ` James R T
2026-01-20 13:59     ` Radim Krčmář

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFSJPWHEF293.2Z6H79QH3IDXR@oss.qualcomm.com \
    --to=radim.krcmar@oss.qualcomm.com \
    --cc=andrew.jones@linux.dev \
    --cc=atishp@rivosinc.com \
    --cc=jamestiotio@gmail.com \
    --cc=opensbi-bounces@lists.infradead.org \
    --cc=opensbi@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox