1. posterid:1774265
  2. A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

Anup Patel
 

The “bypass-sbi” DT property will break QEMU virt machine for KVM because same QEMU virt machine is used with both TCG and KVM acceleration. This is yet another work-around for doing things differently for HS-mode and VS-mode in Linux PMU driver because kernel has no way of knowing which mode kernel is running (HS-mode or VS-mode).

 

The SBI_PMU_COUNTER_START() call can’t be by-passed because the bits which turn-on or turn-off counting are accessible to M-mode only. This SBI_PMU_COUNTER_START() call also takes counter start value provided by Linux PMU framework. We can easily write the counter start value in SBI implementation (M-mode runtime firmware) instead of writing it in S-mode. I still don’t see the benefit of directly writing counter value in S-mode.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 05 August 2020 13:16
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

> 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".
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.