Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

Allen Baum

I may be dense (I won't take a poll on that though), but if a kernel can detect that it is in S-mode vs. VSMode, that sounds like a buggy virtualization scheme. The kernel should (appear to) be in whatever mode it thinks it is, even if it is really in VU mode (with appropriate hypervisor work, and  performance penalties, etc).

On Tue, Aug 4, 2020 at 9:52 PM alankao <alankao@...> wrote:
Hi Anup,

> Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit.

It doesn't matter where the kernel does the update.  What matters is how often kernel does add() and start().  Anyway, it may take a while but we will do the experiment mentioned in previous thread to give real evidence here.

> We should avoid a kernel feature which needs to be explicitly enabled by users and distros keeping it disabled by default. The “#ifdef” based feature checking should be replaced by runtime feature checking based on device tree OR something else.

Is there any way for a kernel to detect if it is in S-mode or VS-mode?  If so, then just don't go that route when writing HPM CSRs.  Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.

Join { to automatically receive all group messages.