Smcntrpmf and Smcdeleg/Ssccfg

[bcstrongx]

I tend to think that RVA23 should include Smcntrpmf and Smcdeleg/Ssccfg.

Since profiles don't cover M-mode extensions, I suppose Smcdeleg would not be included, but Ssccfg would. This would allow the kernel direction write access to Zicntr and Zihpm counters, avoiding the need for SBI calls/returns during perf-sensitive flows like context save/restore.

Smcntrpmf is trickier. It adds support for priv mode filtering of the (m)cycle and (m)instret counters, which is really a fundamental capability that is both helpful to users (eliminates noise) and avoids trust boundary concerns (event counts from more privileged modes being exposed to less privileged modes). Though it is an M-mode extension, it impacts what is visible to S-mode, either via SBI options or when configuring instret/cycle indirectly via Ssccfg. Perhaps there should have been a Sscntrpmf extension for that reason.

[kasanovic]

Ssccfg could possibly be added as an option to the profile, though it is late for changes, and not clear that critical to add given that these are kernel options that can be discovered.
Sscntrpmf can be added as an option in a later minor release, once defined.

[bcstrongx]

I'm not sure I understand why discoverability is relevant. Profiles are about guaranteeing that hardware that conforms to them has a baseline set of extensions.

[kasanovic]

Profiles include both mandatory and optional extensions. It's too late to add mandatory extensions to RVA23/RVB23.