On Tue, Apr 09, 2024 at 05:11:31PM -0700, Atish Patra wrote:
On 4/5/24 05:05, Andrew Jones wrote:
On Tue, Apr 02, 2024 at 01:33:10AM -0700, Atish Patra wrote: ...
but it should be possible for the VMM to disable this extension in the guest. We just need to change all the checks in KVM of the host's ISA for RISCV_ISA_EXT_SSCOFPMF to checking the guest's ISA instead. Maybe it's not worth it, though, if the guest PMU isn't useful without overflow. But, sometimes it's nice to be able to disable stuff for debug and workarounds.
As per my understanding, kvm_riscv_vcpu_isa_disable_allowed only returns true for those extensions which can be disabled architecturally.
I think kvm_riscv_vcpu_isa_disable_allowed can return true for any extensions that KVM can guarantee won't be exposed in any way to the guest. Extensions that cannot be disabled architecturally must return false, since their instructions will still be present in the guest, even if KVM doesn't want to expose them, but extensions which KVM emulates can return true because KVM can choose not to emulate them. IIUC, sscofpmf falls in this latter category.
hmm. The Sscofpmf is dependent on interrupt filtering via hvien and SBI PMU. So you are suggesting to toggle off the CSR_HVIEN bit for overflow interrupt
Yeah, this is what I was thinking.
or do more granular disabling for privilege mode filtering in SBI PMU as well.
Beyond that we can't disable SBI PMU. Is that okay ? A guest can still cause counter overflow and interrupt the host. However, the guest won't get any interrupt as hvien is not set.
It can also still filter the events as that is tied with SBI PMU.
We can put more granular checks in SBI pmu but I am just wondering if it provides anything additional beyond just disabling the sscofpmf in device tree.
If it's too much of a code burden for something we're unlikely going to want to do for anything other than debug (where removing the extension from the device tree is likely sufficient), then that's another reason to not allow disabling. Maybe we should write a comment above kvm_riscv_vcpu_isa_disable_allowed which points how extensions end up there, i.e. either KVM is powerless to completely hide it or we don't want to maintain KVM code to completely hide it.
Thanks, drew