> I think I am repeating myself here but still don’t see any benefit of allowing HPMCOUNTER CSR write access to S-mode. On the contrary, it will make context switching expensive for hypervisors.
I totally am aware of that.  That's why I don't think the same route should be taken in a guest OS.  But since the kernel should not be able to have that knowledge, that is not possible.  I am sorry that I mentioned a condition that confused everyone who shows many interests in H extension. 

Then, please allow me to refine my statement in my previous comment:

> (I asked) Is there any way for a kernel to detect if it is in S-mode or VS-mode?

The answer is no, and should always be not allowed to.

> (I derived) If so, then just don't go that route when writing HPM CSRs.  

But, I would like to claim that this is still possible.  As follows,

> (I stated) 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.

Let me elaborate more. The CONFIG_FPU is true by default.  During system booting, the ISA string in hart nodes in the DTB is checked.  If "fd" is presented, then a global variable has_fpu is set to true; otherwise, false.  Later, during signal handling or context switch, has_fpu is checked.

Why cannot we apply the same path? The CONFIG_RESTRICT_HPM_REG_ACCESS is true by default.  During system booting, the "bypass-sbi" attribute in PMU nodes in the DTB is checked.  If presented, then a global variable mhpm_writable is set to true; otherwise, false.  Later, in PMU life cycles, the variable is checked.  With that flag, the way to update to the desired registers can be decided.  Now the key is in DTB, you can decide that the PMU you are using contains no extra attributes like "bypass-sbi".