KVM: arm64: Don't access PMCR_EL0 when no PMU is available
Subsystems (3)
Marc Zyngier
maintainerPATCH 1/1 KVM: arm64: Don't access PMCR_EL0 when no PMU is available
We reset the guest's view of PMCR_EL0 unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.
The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
--- arch/arm64/kvm/sys_regs.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm64/kvm/sys_regs.c +4 -0
@@ -923,6 +923,10 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) {u64 pmcr, val; +/* No PMU available, PMCR_EL0 may UNDEF... */ +if (!kvm_arm_support_pmu_v3 ()) +return ; + pmcr =read_sysreg (pmcr_el0);/* * Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) are reset to UNKNOWN
Signature · 6 lines
2.29.2 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Marc,
Quoted 25 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")Signed-off-by Marc Zyngier <[email protected]>--- arch/arm64/kvm/sys_regs.c | 4 ++++ 1 file changed, 4 insertions(+)arch/arm64/kvm/sys_regs.c +0
-0
arch/arm64/kvm/sys_regs.c static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) · line 929
Quoted 7 lines
arch/arm64/kvm/sys_regs.c +4
-0@@ -923,6 +923,10 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) {u64 pmcr, val; +/* No PMU available, PMCR_EL0 may UNDEF... */ +if (!kvm_arm_support_pmu_v3 ()) +return ; +
reset_pmcr() is called from kvm_reset_vcpu()->kvm_reset_sys_regs(). Before calling kvm_reset_sys_regs(), kvm_reset_vcpu() returns -EINVAL if the VCPU has the PMUv3 feature but the host doesn't have a PMU.
It looks to me like the undef can happen only when the VCPU feature isn't set and the hardware doesn't have a PMU. How about we change the test to check for kvm_vcpu_has_pmu() to avoid executing the extra instructions, which are not needed because the VM won't have a PMU?
On the other hand, kvm_pmu_vcpu_reset() is happy to do the reset even if the VCPU feature isn't set, the host doesn't support a PMU, and before PMCR_EL0 is initialized. It's up to you, the kvm_arm_support_pmu_v3() check looks consistent with how PMU reset is handled.
Thanks,
Alex
arch/arm64/kvm/sys_regs.c static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) · line 932
Quoted 3 lines
arch/arm64/kvm/sys_regs.c +0
-0pmcr =read_sysreg (pmcr_el0);/* * Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) are reset to UNKNOWN
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerHi Alex,
Thanks for looking at this.
Quoted 41 lines · Alexandru Elisei
Hi Marc,
Quoted 25 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")Signed-off-by Marc Zyngier <[email protected]>--- arch/arm64/kvm/sys_regs.c | 4 ++++ 1 file changed, 4 insertions(+)arch/arm64/kvm/sys_regs.c +0
-0arch/arm64/kvm/sys_regs.c static void reset_pmcr(struct kvm_vcpu *vcpu, · line 930
Quoted 8 lines
arch/arm64/kvm/sys_regs.c +4
-0@@ -923,6 +923,10 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) {u64 pmcr, val; +/* No PMU available, PMCR_EL0 may UNDEF... */ +if (!kvm_arm_support_pmu_v3 ()) +return ; +
reset_pmcr()is called from kvm_reset_vcpu()->kvm_reset_sys_regs(). Before callingkvm_reset_sys_regs(),kvm_reset_vcpu()returns-EINVALif the VCPU has the PMUv3 feature but the host doesn't have a PMU.
Quoted 2 lines
It looks to me like the undef can happen only when the VCPU feature isn't set and the hardware doesn't have a PMU.
Which is exactly what I describe in the commit message (NV without PMU).
Quoted 3 lines
How about we change
the test to check forkvm_vcpu_has_pmu()to avoid executing the extra instructions, which are not needed because the VM won't have a PMU?
I went down that road initially, and then realised that we need to backport this as far back as 4.9 (the code was merged in 4.6). I don't fancy backporting kvm_vcpu_has_pmu() and co...
Thanks,
M.
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Alexandru Elisei
Reviewed-byHi Marc,
Quoted 11 lines · Marc Zyngier
Hi Alex,
Thanks for looking at this.
Quoted 6 lines · Alexandru Elisei
Hi Marc,
Quoted 3 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.
s/imnplementation/implementation
Quoted 35 lines
Quoted 35 lines
Quoted 22 lines
The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")Signed-off-by Marc Zyngier <[email protected]>---
arch/arm64/kvm/sys_regs.c | 4 ++++1 file changed, 4 insertions(+)arch/arm64/kvm/sys_regs.c +0
-0arch/arm64/kvm/sys_regs.c static void reset_pmcr(struct kvm_vcpu *vcpu, const · line 930
Quoted 8 lines
arch/arm64/kvm/sys_regs.c +4
-0@@ -923,6 +923,10 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) { u64 pmcr, val; + /* No PMU available, PMCR_EL0 may UNDEF... */ + if (!kvm_arm_support_pmu_v3()) + return; +
reset_pmcr()is called from kvm_reset_vcpu()->kvm_reset_sys_regs(). Before callingkvm_reset_sys_regs(),kvm_reset_vcpu()returns-EINVALif the VCPU has the PMUv3 feature but the host doesn't have a PMU.
Quoted 4 lines
Quoted 2 lines
It looks to me like the undef can happen only when the VCPU feature isn't set and the hardware doesn't have a PMU.
Which is exactly what I describe in the commit message (NV without PMU).
Yes, I was looking at the code trying to understand how the undef can happen.
Quoted 8 lines
Quoted 4 lines
How about we change
the test to check forkvm_vcpu_has_pmu()to avoid executing the extra instructions, which are not needed because the VM won't have a PMU?I went down that road initially, and then realised that we need to backport this as far back as 4.9 (the code was merged in 4.6). I don't fancy backporting
kvm_vcpu_has_pmu()and co...
Makes sense, and I do consider this approach to be consistent with how we handle PMU reset. The patch looks alright to me:
Thanks,
Alex
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 6 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")Signed-off-by Marc Zyngier <[email protected]>
Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump issue on TX2 while starting a guest.
- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config
# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host -smp 2 -m 2g -drive if=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso -bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:pmevcntr_rawwrite: Assertion `counter < pmu_num_counters(env)' failed.
Quoted 20 lines
--- arch/arm64/kvm/sys_regs.c | 4 ++++ 1 file changed, 4 insertions(+)arch/arm64/kvm/sys_regs.c +4
-0@@ -923,6 +923,10 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r) {u64 pmcr, val; +/* No PMU available, PMCR_EL0 may UNDEF... */ +if (!kvm_arm_support_pmu_v3 ()) +return ; + pmcr =read_sysreg (pmcr_el0);/* * Writable bits of
PMCR_EL0(ARMV8_PMU_PMCR_MASK) are reset to UNKNOWN
Marc Zyngier
maintainerQuoted 33 lines · Qian Cai
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 6 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")Signed-off-by Marc Zyngier <[email protected]>Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump issue on TX2 while starting a guest.
- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host(quoted diff) +0
-2-smp 2 -m 2g -driveif=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso
(quoted diff) +0
-2-bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22
Quoted 2 lines
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:
pmevcntr_rawwrite: Assertion `counter <pmu_num_counters(env)' failed.
You don't have KVM_ARM_PMU selected in your config, so QEMU cannot access the PMU registers, and no counters are exposed.
M.
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 36 lines · Marc Zyngier
Quoted 35 lines · Qian Cai
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 7 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCRregister")
Signed-off-by Marc Zyngier <[email protected]>Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump
issue on TX2 while starting a guest.- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host(quoted diff) +0
-2-smp 2 -m 2g -driveif=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso
(quoted diff) +0
-2-bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22
Quoted 5 lines
Quoted 2 lines
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:
pmevcntr_rawwrite: Assertion `counter <pmu_num_counters(env)' failed.You don't have
KVM_ARM_PMUselected in your config, so QEMU cannot access the PMU registers, and no counters are exposed.
Well, isn't it the rule that don't break the userspace? qemu works fine with KVM_ARM_PMU=n until this commit.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Marc Zyngier
maintainerQuoted 37 lines · Qian Cai
Quoted 36 lines · Marc Zyngier
Quoted 35 lines · Qian Cai
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 7 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCRregister")
Signed-off-by Marc Zyngier <[email protected]>Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump
issue on TX2 while starting a guest.- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host(quoted diff) +0
-2-smp 2 -m 2g -driveif=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso
(quoted diff) +0
-2-bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:
pmevcntr_rawwrite: Assertion `counter <pmu_num_counters(env)' failed.You don't have
KVM_ARM_PMUselected in your config, so QEMU cannot access the PMU registers, and no counters are exposed.Well, isn't it the rule that don't break the userspace? qemu works fine with KVM_ARM_PMU=n until this commit.
No, it doesn't "work fine". It gets random data that potentially makes no sense, depending on the HW this runs on.
Now, userspace tells you that your kernel is misconfigured. I see it as an improvement.
M.
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 48 lines · Marc Zyngier
Quoted 43 lines · Qian Cai
Quoted 36 lines · Marc Zyngier
Quoted 35 lines · Qian Cai
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 7 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCRregister")
Signed-off-by Marc Zyngier <[email protected]>Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump
issue on TX2 while starting a guest.- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host(quoted diff) +0
-2-smp 2 -m 2g -driveif=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso
(quoted diff) +0
-2-bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22Quoted 5 lines
Quoted 2 lines
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:
pmevcntr_rawwrite: Assertion `counter <pmu_num_counters(env)' failed.You don't have
KVM_ARM_PMUselected in your config, so QEMU cannot access the PMU registers, and no counters are exposed.Quoted 3 lines
Well, isn't it the rule that don't break the userspace? qemu works fine with
KVM_ARM_PMU=n until this commit.
Quoted 6 lines
No, it doesn't "work fine". It gets random data that potentially makes no sense,
depending on the HW this runs on.Now, userspace tells you that your kernel is misconfigured. I see it as an improvement.
Marc, do you suggest that CONFIG_KVM=y should select KVM_ARM_PMU=y then? Otherwise, this is rather difficult for users to figure out and a core dump with an implicit error message from qemu is not that helpful.
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerQuoted 53 lines · Qian Cai
Quoted 52 lines · Marc Zyngier
Quoted 43 lines · Qian Cai
Quoted 36 lines · Marc Zyngier
Quoted 35 lines · Qian Cai
Quoted 10 lines · Marc Zyngier
We reset the guest's view of
PMCR_EL0unconditionally, based on the host's view of this register. It is however legal for an imnplementation not to provide any PMU, resulting in an UNDEF.The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do!
Quoted 7 lines
It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself.
Fixes ab9468340d2bc ("arm64: KVM: Add access handler for PMCRregister")
Signed-off-by Marc Zyngier <[email protected]>Reverting this commit on the top of today's linux-next fixed a qemu-kvm coredump
issue on TX2 while starting a guest.- host kernel .config:
https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config# /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host(quoted diff) +0
-2-smp 2 -m 2g -driveif=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd -device virtio-scsi -device scsi-hd,drive=hd -cdrom ./ubuntu-20.04-server-cloudimg.iso
(quoted diff) +0
-2-bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic -nic user,model=virtio,hostfwd=tcp::2222-:22Quoted 5 lines
Quoted 2 lines
qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812:
pmevcntr_rawwrite: Assertion `counter <pmu_num_counters(env)' failed.You don't have
KVM_ARM_PMUselected in your config, so QEMU cannot access the PMU registers, and no counters are exposed.Quoted 3 lines
Well, isn't it the rule that don't break the userspace? qemu works fine with
KVM_ARM_PMU=n until this commit.No, it doesn't "work fine". It gets random data that potentially makes no sense,
depending on the HW this runs on.
Quoted 6 lines
Quoted 2 lines
Now, userspace tells you that your kernel is misconfigured. I see it as an improvement.
Marc, do you suggest that
CONFIG_KVM=yshould select KVM_ARM_PMU=y then? Otherwise, this is rather difficult for users to figure out and a core dump with an implicit error message from qemu is not that helpful.
What I'm suggesting is this [1], which is to get rid of KVM_ARM_PMU completely. At least, the kernel configuration will be consistent.
Overall, I think there is an issue with KVM exposing more than it should to userspace when no PMU is defined, but I don't think that's the problem you are seeing.
M.
[1] https://lore.kernel.org/r/[email protected]
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 3 lines · Marc Zyngier
What I'm suggesting is this [1], which is to get rid of
KVM_ARM_PMUcompletely. At least, the kernel configuration will be consistent.
Do you have a patch for CONFIG_KVM to select HW_PERF_EVENTS then? I could cook one if not.
Quoted 7 lines
Overall, I think there is an issue with KVM exposing more than it should to userspace when no PMU is defined, but I don't think that's the problem you are seeing.
M.
Marc Zyngier
maintainerQuoted 7 lines · Qian Cai
Quoted 3 lines · Marc Zyngier
What I'm suggesting is this [1], which is to get rid of
KVM_ARM_PMUcompletely. At least, the kernel configuration will be consistent.Do you have a patch for
CONFIG_KVMto selectHW_PERF_EVENTSthen? I could cook one if not.
I don't think there should be such a patch. People do disable HW_PERF_EVENTS in production in some cases, and we should honor that. All I am trying to guarantee at the moment is that the KVM configuration is consistent, as I believe that's what broke in your particular case.
What needs doing is to hide the PMU registers from userspace when no PMU is configured, or even available. I'll try and post something to that effect tomorrow (hey, I'm still officially on holiday...).
M.
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm