* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.
Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.
Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.
Host:
Performance counter stats for 'sleep 5' (5 runs):
0.549456 task-clock (msec) # 0.000 CPUs utilized ( +- 5.68% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
48 page-faults # 0.088 M/sec ( +- 1.40% )
1146243 cycles # 2.086 GHz ( +- 5.71% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
627195 instructions # 0.55 insns per cycle ( +- 15.65% )
<not supported> branches
9826 branch-misses # 17.883 M/sec ( +- 1.10% )
5.000875516 seconds time elapsed ( +- 0.00% )
Guest:
Performance counter stats for 'sleep 5' (5 runs):
0.640712 task-clock (msec) # 0.000 CPUs utilized ( +- 0.41% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
50 page-faults # 0.077 M/sec ( +- 1.37% )
1320428 cycles # 2.061 GHz ( +- 0.29% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
642373 instructions # 0.49 insns per cycle ( +- 0.46% )
<not supported> branches
10399 branch-misses # 16.230 M/sec ( +- 1.57% )
5.001181020 seconds time elapsed ( +- 0.00% )
Have a cycle counter read test like below in guest and host:
static void test(void)
{
unsigned long count, count1, count2;
count1 = read_cycles();
count++;
count2 = read_cycles();
}
Host:
count1: 3049567104
count2: 3049567247
delta: 143
Guest:
count1: 5281420890
count2: 5281421068
delta: 178
The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.
This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].
The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].
Also, I have tested "perf top" in two VMs and host at the same time. It
works well.
Thanks,
Shannon
[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git KVM_ARM64_PMU_v8
[2] https://git.linaro.org/people/shannon.zhao/qemu.git virtual_PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt
Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
EL1
* Fix some small bugs found by Marc
Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
arch64 and arch32. And it could drop the definitions of CP15 register
offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()
Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc
Changes since v4:
* Rebase on new linux kernel mainline
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range
Changes since v3:
* Rebase on new linux kernel mainline
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2
Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file
Changes since v1:
* Use switch...case for registers access handler instead of adding
alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
create PMU
* Fix the handle of PMU overflow interrupt
Shannon Zhao (20):
ARM64: Move PMU register related defines to asm/pmu.h
KVM: ARM64: Define PMU data structure for each vcpu
KVM: ARM64: Add offset defines for PMU registers
KVM: ARM64: Add access handler for PMCR register
KVM: ARM64: Add access handler for PMSELR register
KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
KVM: ARM64: PMU: Add perf event map and introduce perf event creating
function
KVM: ARM64: Add access handler for event typer register
KVM: ARM64: Add access handler for event counter register
KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
KVM: ARM64: Add access handler for PMSWINC register
KVM: ARM64: Add helper to handle PMCR register bits
KVM: ARM64: Add a helper to forward trap to guest EL1
KVM: ARM64: Add access handler for PMUSERENR register
KVM: ARM64: Add PMU overflow interrupt routing
KVM: ARM64: Reset PMU state when resetting vcpu
KVM: ARM64: Free perf event of PMU when destroying vcpu
KVM: ARM64: Add a new kvm ARM PMU device
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 ++
arch/arm/kvm/arm.c | 3 +
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/include/asm/kvm_host.h | 17 +
arch/arm64/include/asm/pmu.h | 79 ++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
arch/arm64/kernel/perf_event.c | 36 +-
arch/arm64/kvm/Kconfig | 7 +
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/hyp/switch.c | 3 +
arch/arm64/kvm/inject_fault.c | 52 ++-
arch/arm64/kvm/reset.c | 3 +
arch/arm64/kvm/sys_regs.c | 598 ++++++++++++++++++++++++--
include/kvm/arm_pmu.h | 74 ++++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 504 ++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
18 files changed, 1348 insertions(+), 65 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
create mode 100644 arch/arm64/include/asm/pmu.h
create mode 100644 include/kvm/arm_pmu.h
create mode 100644 virt/kvm/arm/pmu.c
--
2.0.4
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.
Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.
Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.
Host:
Performance counter stats for 'sleep 5' (5 runs):
0.549456 task-clock (msec) # 0.000 CPUs utilized ( +- 5.68% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
48 page-faults # 0.088 M/sec ( +- 1.40% )
1146243 cycles # 2.086 GHz ( +- 5.71% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
627195 instructions # 0.55 insns per cycle ( +- 15.65% )
<not supported> branches
9826 branch-misses # 17.883 M/sec ( +- 1.10% )
5.000875516 seconds time elapsed ( +- 0.00% )
Guest:
Performance counter stats for 'sleep 5' (5 runs):
0.640712 task-clock (msec) # 0.000 CPUs utilized ( +- 0.41% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
50 page-faults # 0.077 M/sec ( +- 1.37% )
1320428 cycles # 2.061 GHz ( +- 0.29% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
642373 instructions # 0.49 insns per cycle ( +- 0.46% )
<not supported> branches
10399 branch-misses # 16.230 M/sec ( +- 1.57% )
5.001181020 seconds time elapsed ( +- 0.00% )
Have a cycle counter read test like below in guest and host:
static void test(void)
{
unsigned long count, count1, count2;
count1 = read_cycles();
count++;
count2 = read_cycles();
}
Host:
count1: 3049567104
count2: 3049567247
delta: 143
Guest:
count1: 5281420890
count2: 5281421068
delta: 178
The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.
This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].
The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].
Also, I have tested "perf top" in two VMs and host at the same time. It
works well.
Thanks,
Shannon
[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git KVM_ARM64_PMU_v8
[2] https://git.linaro.org/people/shannon.zhao/qemu.git virtual_PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt
Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
EL1
* Fix some small bugs found by Marc
Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
arch64 and arch32. And it could drop the definitions of CP15 register
offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()
Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc
Changes since v4:
* Rebase on new linux kernel mainline
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range
Changes since v3:
* Rebase on new linux kernel mainline
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2
Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file
Changes since v1:
* Use switch...case for registers access handler instead of adding
alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
create PMU
* Fix the handle of PMU overflow interrupt
Shannon Zhao (20):
ARM64: Move PMU register related defines to asm/pmu.h
KVM: ARM64: Define PMU data structure for each vcpu
KVM: ARM64: Add offset defines for PMU registers
KVM: ARM64: Add access handler for PMCR register
KVM: ARM64: Add access handler for PMSELR register
KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
KVM: ARM64: PMU: Add perf event map and introduce perf event creating
function
KVM: ARM64: Add access handler for event typer register
KVM: ARM64: Add access handler for event counter register
KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
KVM: ARM64: Add access handler for PMSWINC register
KVM: ARM64: Add helper to handle PMCR register bits
KVM: ARM64: Add a helper to forward trap to guest EL1
KVM: ARM64: Add access handler for PMUSERENR register
KVM: ARM64: Add PMU overflow interrupt routing
KVM: ARM64: Reset PMU state when resetting vcpu
KVM: ARM64: Free perf event of PMU when destroying vcpu
KVM: ARM64: Add a new kvm ARM PMU device
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 ++
arch/arm/kvm/arm.c | 3 +
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/include/asm/kvm_host.h | 17 +
arch/arm64/include/asm/pmu.h | 79 ++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
arch/arm64/kernel/perf_event.c | 36 +-
arch/arm64/kvm/Kconfig | 7 +
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/hyp/switch.c | 3 +
arch/arm64/kvm/inject_fault.c | 52 ++-
arch/arm64/kvm/reset.c | 3 +
arch/arm64/kvm/sys_regs.c | 598 ++++++++++++++++++++++++--
include/kvm/arm_pmu.h | 74 ++++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 504 ++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
18 files changed, 1348 insertions(+), 65 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
create mode 100644 arch/arm64/include/asm/pmu.h
create mode 100644 include/kvm/arm_pmu.h
create mode 100644 virt/kvm/arm/pmu.c
--
2.0.4
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.
Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.
Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.
Host:
Performance counter stats for 'sleep 5' (5 runs):
0.549456 task-clock (msec) # 0.000 CPUs utilized ( +- 5.68% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
48 page-faults # 0.088 M/sec ( +- 1.40% )
1146243 cycles # 2.086 GHz ( +- 5.71% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
627195 instructions # 0.55 insns per cycle ( +- 15.65% )
<not supported> branches
9826 branch-misses # 17.883 M/sec ( +- 1.10% )
5.000875516 seconds time elapsed ( +- 0.00% )
Guest:
Performance counter stats for 'sleep 5' (5 runs):
0.640712 task-clock (msec) # 0.000 CPUs utilized ( +- 0.41% )
1 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
50 page-faults # 0.077 M/sec ( +- 1.37% )
1320428 cycles # 2.061 GHz ( +- 0.29% )
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
642373 instructions # 0.49 insns per cycle ( +- 0.46% )
<not supported> branches
10399 branch-misses # 16.230 M/sec ( +- 1.57% )
5.001181020 seconds time elapsed ( +- 0.00% )
Have a cycle counter read test like below in guest and host:
static void test(void)
{
unsigned long count, count1, count2;
count1 = read_cycles();
count++;
count2 = read_cycles();
}
Host:
count1: 3049567104
count2: 3049567247
delta: 143
Guest:
count1: 5281420890
count2: 5281421068
delta: 178
The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.
This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].
The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].
Also, I have tested "perf top" in two VMs and host at the same time. It
works well.
Thanks,
Shannon
[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git KVM_ARM64_PMU_v8
[2] https://git.linaro.org/people/shannon.zhao/qemu.git virtual_PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt
Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
EL1
* Fix some small bugs found by Marc
Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
arch64 and arch32. And it could drop the definitions of CP15 register
offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()
Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc
Changes since v4:
* Rebase on new linux kernel mainline
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range
Changes since v3:
* Rebase on new linux kernel mainline
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2
Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file
Changes since v1:
* Use switch...case for registers access handler instead of adding
alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
create PMU
* Fix the handle of PMU overflow interrupt
Shannon Zhao (20):
ARM64: Move PMU register related defines to asm/pmu.h
KVM: ARM64: Define PMU data structure for each vcpu
KVM: ARM64: Add offset defines for PMU registers
KVM: ARM64: Add access handler for PMCR register
KVM: ARM64: Add access handler for PMSELR register
KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
KVM: ARM64: PMU: Add perf event map and introduce perf event creating
function
KVM: ARM64: Add access handler for event typer register
KVM: ARM64: Add access handler for event counter register
KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
KVM: ARM64: Add access handler for PMSWINC register
KVM: ARM64: Add helper to handle PMCR register bits
KVM: ARM64: Add a helper to forward trap to guest EL1
KVM: ARM64: Add access handler for PMUSERENR register
KVM: ARM64: Add PMU overflow interrupt routing
KVM: ARM64: Reset PMU state when resetting vcpu
KVM: ARM64: Free perf event of PMU when destroying vcpu
KVM: ARM64: Add a new kvm ARM PMU device
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 ++
arch/arm/kvm/arm.c | 3 +
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/include/asm/kvm_host.h | 17 +
arch/arm64/include/asm/pmu.h | 79 ++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
arch/arm64/kernel/perf_event.c | 36 +-
arch/arm64/kvm/Kconfig | 7 +
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/hyp/switch.c | 3 +
arch/arm64/kvm/inject_fault.c | 52 ++-
arch/arm64/kvm/reset.c | 3 +
arch/arm64/kvm/sys_regs.c | 598 ++++++++++++++++++++++++--
include/kvm/arm_pmu.h | 74 ++++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 504 ++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
18 files changed, 1348 insertions(+), 65 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
create mode 100644 arch/arm64/include/asm/pmu.h
create mode 100644 include/kvm/arm_pmu.h
create mode 100644 virt/kvm/arm/pmu.c
--
2.0.4
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:07 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
To use the ARMv8 PMU related register defines from the KVM code,
we move the relevant definitions to asm/pmu.h header file.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 67 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/perf_event.c | 36 +----------------------
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 arch/arm64/include/asm/pmu.h
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
new file mode 100644
index 0000000..4406184
--- /dev/null
+++ b/arch/arm64/include/asm/pmu.h
@@ -0,0 +1,67 @@
+/*
+ * PMU support
+ *
+ * Copyright (C) 2012 ARM Limited
+ * Author: Will Deacon <will.deacon@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_PMU_H
+#define __ASM_PMU_H
+
+#define ARMV8_MAX_COUNTERS 32
+#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
+#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
+#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
+#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
+#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
+#define ARMV8_PMCR_N_MASK 0x1f
+#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
+
+/*
+ * PMCNTEN: counters enable reg
+ */
+#define ARMV8_CNTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMINTEN: counters interrupt enable reg
+ */
+#define ARMV8_INTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
+#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
+#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define ARMV8_EXCLUDE_EL1 (1 << 31)
+#define ARMV8_EXCLUDE_EL0 (1 << 30)
+#define ARMV8_INCLUDE_EL2 (1 << 27)
+
+#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5b1897e..7eca5dc 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
#include <linux/of.h>
#include <linux/perf/arm_pmu.h>
#include <linux/platform_device.h>
+#include <asm/pmu.h>
/*
* ARMv8 PMUv3 Performance Events handling code.
@@ -187,9 +188,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
-#define ARMV8_MAX_COUNTERS 32
-#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
-
/*
* ARMv8 low level PMU access
*/
@@ -200,38 +198,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_TO_COUNTER(x) \
(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
-#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
-#define ARMV8_PMCR_N_MASK 0x1f
-#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
-#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
-#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define ARMV8_EXCLUDE_EL1 (1 << 31)
-#define ARMV8_EXCLUDE_EL0 (1 << 30)
-#define ARMV8_INCLUDE_EL2 (1 << 27)
-
static inline u32 armv8pmu_pmcr_read(void)
{
u32 val;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
To use the ARMv8 PMU related register defines from the KVM code,
we move the relevant definitions to asm/pmu.h header file.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 67 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/perf_event.c | 36 +----------------------
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 arch/arm64/include/asm/pmu.h
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
new file mode 100644
index 0000000..4406184
--- /dev/null
+++ b/arch/arm64/include/asm/pmu.h
@@ -0,0 +1,67 @@
+/*
+ * PMU support
+ *
+ * Copyright (C) 2012 ARM Limited
+ * Author: Will Deacon <will.deacon@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_PMU_H
+#define __ASM_PMU_H
+
+#define ARMV8_MAX_COUNTERS 32
+#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
+#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
+#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
+#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
+#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
+#define ARMV8_PMCR_N_MASK 0x1f
+#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
+
+/*
+ * PMCNTEN: counters enable reg
+ */
+#define ARMV8_CNTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMINTEN: counters interrupt enable reg
+ */
+#define ARMV8_INTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
+#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
+#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define ARMV8_EXCLUDE_EL1 (1 << 31)
+#define ARMV8_EXCLUDE_EL0 (1 << 30)
+#define ARMV8_INCLUDE_EL2 (1 << 27)
+
+#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5b1897e..7eca5dc 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
#include <linux/of.h>
#include <linux/perf/arm_pmu.h>
#include <linux/platform_device.h>
+#include <asm/pmu.h>
/*
* ARMv8 PMUv3 Performance Events handling code.
@@ -187,9 +188,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
-#define ARMV8_MAX_COUNTERS 32
-#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
-
/*
* ARMv8 low level PMU access
*/
@@ -200,38 +198,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_TO_COUNTER(x) \
(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
-#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
-#define ARMV8_PMCR_N_MASK 0x1f
-#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
-#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
-#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define ARMV8_EXCLUDE_EL1 (1 << 31)
-#define ARMV8_EXCLUDE_EL0 (1 << 30)
-#define ARMV8_INCLUDE_EL2 (1 << 27)
-
static inline u32 armv8pmu_pmcr_read(void)
{
u32 val;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
To use the ARMv8 PMU related register defines from the KVM code,
we move the relevant definitions to asm/pmu.h header file.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 67 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/perf_event.c | 36 +----------------------
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 arch/arm64/include/asm/pmu.h
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
new file mode 100644
index 0000000..4406184
--- /dev/null
+++ b/arch/arm64/include/asm/pmu.h
@@ -0,0 +1,67 @@
+/*
+ * PMU support
+ *
+ * Copyright (C) 2012 ARM Limited
+ * Author: Will Deacon <will.deacon@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_PMU_H
+#define __ASM_PMU_H
+
+#define ARMV8_MAX_COUNTERS 32
+#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
+#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
+#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
+#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
+#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
+#define ARMV8_PMCR_N_MASK 0x1f
+#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
+
+/*
+ * PMCNTEN: counters enable reg
+ */
+#define ARMV8_CNTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMINTEN: counters interrupt enable reg
+ */
+#define ARMV8_INTEN_MASK 0xffffffff /* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
+#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
+#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define ARMV8_EXCLUDE_EL1 (1 << 31)
+#define ARMV8_EXCLUDE_EL0 (1 << 30)
+#define ARMV8_INCLUDE_EL2 (1 << 27)
+
+#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5b1897e..7eca5dc 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
#include <linux/of.h>
#include <linux/perf/arm_pmu.h>
#include <linux/platform_device.h>
+#include <asm/pmu.h>
/*
* ARMv8 PMUv3 Performance Events handling code.
@@ -187,9 +188,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
-#define ARMV8_MAX_COUNTERS 32
-#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
-
/*
* ARMv8 low level PMU access
*/
@@ -200,38 +198,6 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
#define ARMV8_IDX_TO_COUNTER(x) \
(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E (1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P (1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C (1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
-#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
-#define ARMV8_PMCR_N_MASK 0x1f
-#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define ARMV8_OVSR_MASK 0xffffffff /* Mask for writable bits */
-#define ARMV8_OVERFLOWED_MASK ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define ARMV8_EVTYPE_MASK 0xc80003ff /* Mask for writable bits */
-#define ARMV8_EVTYPE_EVENT 0x3ff /* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define ARMV8_EXCLUDE_EL1 (1 << 31)
-#define ARMV8_EXCLUDE_EL0 (1 << 30)
-#define ARMV8_INCLUDE_EL2 (1 << 27)
-
static inline u32 armv8pmu_pmcr_read(void)
{
u32 val;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:07 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kvm/Kconfig | 7 +++++++
include/kvm/arm_pmu.h | 42 +++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 include/kvm/arm_pmu.h
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
/* VGIC state */
struct vgic_cpu vgic_cpu;
struct arch_timer_cpu timer_cpu;
+ struct kvm_pmu pmu;
/*
* Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
select KVM_ARM_VGIC_V3
+ select KVM_ARM_PMU if HW_PERF_EVENTS
---help---
Support hosting virtualized guest machines.
We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
---help---
Provides host support for ARM processors.
+config KVM_ARM_PMU
+ bool
+ ---help---
+ Adds support for a virtual Performance Monitoring Unit (PMU) in
+ virtual machines.
+
source drivers/vhost/Kconfig
endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..ddcb5b2
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/pmu.h>
+
+struct kvm_pmc {
+ u8 idx;/* index into the pmu->pmc array */
+ struct perf_event *perf_event;
+ u64 bitmask;
+};
+
+struct kvm_pmu {
+ /* PMU IRQ Number per VCPU */
+ int irq_num;
+ struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kvm/Kconfig | 7 +++++++
include/kvm/arm_pmu.h | 42 +++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 include/kvm/arm_pmu.h
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
/* VGIC state */
struct vgic_cpu vgic_cpu;
struct arch_timer_cpu timer_cpu;
+ struct kvm_pmu pmu;
/*
* Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
select KVM_ARM_VGIC_V3
+ select KVM_ARM_PMU if HW_PERF_EVENTS
---help---
Support hosting virtualized guest machines.
We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
---help---
Provides host support for ARM processors.
+config KVM_ARM_PMU
+ bool
+ ---help---
+ Adds support for a virtual Performance Monitoring Unit (PMU) in
+ virtual machines.
+
source drivers/vhost/Kconfig
endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..ddcb5b2
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/pmu.h>
+
+struct kvm_pmc {
+ u8 idx;/* index into the pmu->pmc array */
+ struct perf_event *perf_event;
+ u64 bitmask;
+};
+
+struct kvm_pmu {
+ /* PMU IRQ Number per VCPU */
+ int irq_num;
+ struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kvm/Kconfig | 7 +++++++
include/kvm/arm_pmu.h | 42 +++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 include/kvm/arm_pmu.h
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
/* VGIC state */
struct vgic_cpu vgic_cpu;
struct arch_timer_cpu timer_cpu;
+ struct kvm_pmu pmu;
/*
* Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
select KVM_ARM_VGIC_V3
+ select KVM_ARM_PMU if HW_PERF_EVENTS
---help---
Support hosting virtualized guest machines.
We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
---help---
Provides host support for ARM processors.
+config KVM_ARM_PMU
+ bool
+ ---help---
+ Adds support for a virtual Performance Monitoring Unit (PMU) in
+ virtual machines.
+
source drivers/vhost/Kconfig
endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..ddcb5b2
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/pmu.h>
+
+struct kvm_pmc {
+ u8 idx;/* index into the pmu->pmc array */
+ struct perf_event *perf_event;
+ u64 bitmask;
+};
+
+struct kvm_pmu {
+ /* PMU IRQ Number per VCPU */
+ int irq_num;
+ struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:07 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
We are about to trap and emulate accesses to each PMU register
individually. This adds the context offsets for the AArch64 PMU
registers.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..6bab7fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,21 @@ enum vcpu_sysreg {
MDSCR_EL1, /* Monitor Debug System Control Register */
MDCCINT_EL1, /* Monitor Debug Comms Channel Interrupt Enable Reg */
+ /* Performance Monitors Registers */
+ PMCR_EL0, /* Control Register */
+ PMOVSSET_EL0, /* Overflow Flag Status Set Register */
+ PMSELR_EL0, /* Event Counter Selection Register */
+ PMEVCNTR0_EL0, /* Event Counter Register (0-30) */
+ PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+ PMCCNTR_EL0, /* Cycle Counter Register */
+ PMEVTYPER0_EL0, /* Event Type Register (0-30) */
+ PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+ PMCCFILTR_EL0, /* Cycle Count Filter Register */
+ PMCNTENSET_EL0, /* Count Enable Set Register */
+ PMINTENSET_EL1, /* Interrupt Enable Set Register */
+ PMUSERENR_EL0, /* User Enable Register */
+ PMSWINC_EL0, /* Software Increment Register */
+
/* 32bit specific registers. Keep them at the end of the range */
DACR32_EL2, /* Domain Access Control Register */
IFSR32_EL2, /* Instruction Fault Status Register */
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
We are about to trap and emulate accesses to each PMU register
individually. This adds the context offsets for the AArch64 PMU
registers.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..6bab7fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,21 @@ enum vcpu_sysreg {
MDSCR_EL1, /* Monitor Debug System Control Register */
MDCCINT_EL1, /* Monitor Debug Comms Channel Interrupt Enable Reg */
+ /* Performance Monitors Registers */
+ PMCR_EL0, /* Control Register */
+ PMOVSSET_EL0, /* Overflow Flag Status Set Register */
+ PMSELR_EL0, /* Event Counter Selection Register */
+ PMEVCNTR0_EL0, /* Event Counter Register (0-30) */
+ PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+ PMCCNTR_EL0, /* Cycle Counter Register */
+ PMEVTYPER0_EL0, /* Event Type Register (0-30) */
+ PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+ PMCCFILTR_EL0, /* Cycle Count Filter Register */
+ PMCNTENSET_EL0, /* Count Enable Set Register */
+ PMINTENSET_EL1, /* Interrupt Enable Set Register */
+ PMUSERENR_EL0, /* User Enable Register */
+ PMSWINC_EL0, /* Software Increment Register */
+
/* 32bit specific registers. Keep them at the end of the range */
DACR32_EL2, /* Domain Access Control Register */
IFSR32_EL2, /* Instruction Fault Status Register */
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
We are about to trap and emulate accesses to each PMU register
individually. This adds the context offsets for the AArch64 PMU
registers.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..6bab7fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,21 @@ enum vcpu_sysreg {
MDSCR_EL1, /* Monitor Debug System Control Register */
MDCCINT_EL1, /* Monitor Debug Comms Channel Interrupt Enable Reg */
+ /* Performance Monitors Registers */
+ PMCR_EL0, /* Control Register */
+ PMOVSSET_EL0, /* Overflow Flag Status Set Register */
+ PMSELR_EL0, /* Event Counter Selection Register */
+ PMEVCNTR0_EL0, /* Event Counter Register (0-30) */
+ PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+ PMCCNTR_EL0, /* Cycle Counter Register */
+ PMEVTYPER0_EL0, /* Event Type Register (0-30) */
+ PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+ PMCCFILTR_EL0, /* Cycle Count Filter Register */
+ PMCNTENSET_EL0, /* Count Enable Set Register */
+ PMINTENSET_EL1, /* Interrupt Enable Set Register */
+ PMUSERENR_EL0, /* User Enable Register */
+ PMSWINC_EL0, /* Software Increment Register */
+
/* 32bit specific registers. Keep them at the end of the range */
DACR32_EL2, /* Domain Access Control Register */
IFSR32_EL2, /* Instruction Fault Status Register */
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:07 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e8bf374..c60047e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
#include <asm/kvm_emulate.h>
#include <asm/kvm_host.h>
#include <asm/kvm_mmu.h>
+#include <asm/pmu.h>
#include <trace/events/kvm.h>
@@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
}
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+ u64 pmcr, val;
+
+ asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+ /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
+ * except PMCR.E resetting to zero.
+ */
+ val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
+ & (~ARMV8_PMCR_E);
+ vcpu_sys_reg(vcpu, r->reg) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val;
+
+ if (p->is_write) {
+ /* Only update writeable bits of PMCR */
+ val = vcpu_sys_reg(vcpu, r->reg);
+ val &= ~ARMV8_PMCR_MASK;
+ val |= p->regval & ARMV8_PMCR_MASK;
+ vcpu_sys_reg(vcpu, r->reg) = val;
+ } else {
+ /* PMCR.P & PMCR.C are RAZ */
+ val = vcpu_sys_reg(vcpu, r->reg)
+ & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
+ p->regval = val;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -623,7 +658,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMCR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
- trap_raz_wi },
+ access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
trap_raz_wi },
@@ -885,7 +920,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
/* PMU */
- { Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e8bf374..c60047e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
#include <asm/kvm_emulate.h>
#include <asm/kvm_host.h>
#include <asm/kvm_mmu.h>
+#include <asm/pmu.h>
#include <trace/events/kvm.h>
@@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
}
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+ u64 pmcr, val;
+
+ asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+ /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
+ * except PMCR.E resetting to zero.
+ */
+ val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
+ & (~ARMV8_PMCR_E);
+ vcpu_sys_reg(vcpu, r->reg) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val;
+
+ if (p->is_write) {
+ /* Only update writeable bits of PMCR */
+ val = vcpu_sys_reg(vcpu, r->reg);
+ val &= ~ARMV8_PMCR_MASK;
+ val |= p->regval & ARMV8_PMCR_MASK;
+ vcpu_sys_reg(vcpu, r->reg) = val;
+ } else {
+ /* PMCR.P & PMCR.C are RAZ */
+ val = vcpu_sys_reg(vcpu, r->reg)
+ & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
+ p->regval = val;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -623,7 +658,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMCR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
- trap_raz_wi },
+ access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
trap_raz_wi },
@@ -885,7 +920,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
/* PMU */
- { Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
@ 2015-12-22 8:07 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e8bf374..c60047e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
#include <asm/kvm_emulate.h>
#include <asm/kvm_host.h>
#include <asm/kvm_mmu.h>
+#include <asm/pmu.h>
#include <trace/events/kvm.h>
@@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
}
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+ u64 pmcr, val;
+
+ asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+ /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
+ * except PMCR.E resetting to zero.
+ */
+ val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
+ & (~ARMV8_PMCR_E);
+ vcpu_sys_reg(vcpu, r->reg) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val;
+
+ if (p->is_write) {
+ /* Only update writeable bits of PMCR */
+ val = vcpu_sys_reg(vcpu, r->reg);
+ val &= ~ARMV8_PMCR_MASK;
+ val |= p->regval & ARMV8_PMCR_MASK;
+ vcpu_sys_reg(vcpu, r->reg) = val;
+ } else {
+ /* PMCR.P & PMCR.C are RAZ */
+ val = vcpu_sys_reg(vcpu, r->reg)
+ & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
+ p->regval = val;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -623,7 +658,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMCR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
- trap_raz_wi },
+ access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
trap_raz_wi },
@@ -885,7 +920,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
/* PMU */
- { Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c60047e..f9985fc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -474,6 +474,18 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, r->reg) = p->regval;
+ else
+ /* return PMSELR.SEL field */
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_COUNTER_MASK;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -673,7 +685,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
- trap_raz_wi },
+ access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
trap_raz_wi },
@@ -924,7 +936,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c60047e..f9985fc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -474,6 +474,18 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, r->reg) = p->regval;
+ else
+ /* return PMSELR.SEL field */
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_COUNTER_MASK;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -673,7 +685,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
- trap_raz_wi },
+ access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
trap_raz_wi },
@@ -924,7 +936,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c60047e..f9985fc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -474,6 +474,18 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, r->reg) = p->regval;
+ else
+ /* return PMSELR.SEL field */
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_COUNTER_MASK;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -673,7 +685,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
- trap_raz_wi },
+ access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
trap_raz_wi },
@@ -924,7 +936,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f9985fc..2552db1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -486,6 +486,25 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 pmceid;
+
+ if (p->is_write) {
+ kvm_inject_undefined(vcpu);
+ } else {
+ if (!(p->Op2 & 1))
+ asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+ else
+ asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+ p->regval = pmceid;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -688,10 +707,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
- trap_raz_wi },
+ access_pmceid },
/* PMCEID1_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
- trap_raz_wi },
+ access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
trap_raz_wi },
@@ -937,8 +956,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f9985fc..2552db1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -486,6 +486,25 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 pmceid;
+
+ if (p->is_write) {
+ kvm_inject_undefined(vcpu);
+ } else {
+ if (!(p->Op2 & 1))
+ asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+ else
+ asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+ p->regval = pmceid;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -688,10 +707,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
- trap_raz_wi },
+ access_pmceid },
/* PMCEID1_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
- trap_raz_wi },
+ access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
trap_raz_wi },
@@ -937,8 +956,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f9985fc..2552db1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -486,6 +486,25 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 pmceid;
+
+ if (p->is_write) {
+ kvm_inject_undefined(vcpu);
+ } else {
+ if (!(p->Op2 & 1))
+ asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+ else
+ asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+ p->regval = pmceid;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -688,10 +707,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmselr, reset_unknown, PMSELR_EL0 },
/* PMCEID0_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
- trap_raz_wi },
+ access_pmceid },
/* PMCEID1_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
- trap_raz_wi },
+ access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
trap_raz_wi },
@@ -937,8 +956,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 3 ++
arch/arm64/kvm/Makefile | 1 +
include/kvm/arm_pmu.h | 11 ++++
virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 137 insertions(+)
create mode 100644 virt/kvm/arm/pmu.c
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 4406184..2588f9c 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -21,6 +21,7 @@
#define ARMV8_MAX_COUNTERS 32
#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
/*
* Per-CPU PMCR: config reg
@@ -31,6 +32,8 @@
#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which PMCCNTR_EL0 bit generates an overflow */
+#define ARMV8_PMCR_LC (1 << 6)
#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
#define ARMV8_PMCR_N_MASK 0x1f
#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index ddcb5b2..14bedb0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,20 @@ struct kvm_pmu {
int irq_num;
struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx);
#else
struct kvm_pmu {
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ return 0;
+}
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx) {}
#endif
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..9d27999
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ u64 counter, reg, enabled, running;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+ reg = (select_idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+ counter = vcpu_sys_reg(vcpu, reg);
+
+ /* The real counter value is equal to the value of counter register plus
+ * the value perf event counts.
+ */
+ if (pmc->perf_event)
+ counter += perf_event_read_value(pmc->perf_event, &enabled,
+ &running);
+
+ return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+ u64 counter, reg;
+
+ if (pmc->perf_event) {
+ counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+ reg = (pmc->idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+ vcpu_sys_reg(vcpu, reg) = counter;
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+}
+
+static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
+ u64 select_idx)
+{
+ return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
+ (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+ struct perf_event *event;
+ struct perf_event_attr attr;
+ u64 eventsel, counter;
+
+ kvm_pmu_stop_counter(vcpu, pmc);
+ eventsel = data & ARMV8_EVTYPE_EVENT;
+
+ memset(&attr, 0, sizeof(struct perf_event_attr));
+ attr.type = PERF_TYPE_RAW;
+ attr.size = sizeof(attr);
+ attr.pinned = 1;
+ attr.disabled = kvm_pmu_counter_is_enabled(vcpu, select_idx);
+ attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
+ attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
+ attr.exclude_hv = 1; /* Don't count EL2 events */
+ attr.exclude_host = 1; /* Don't count host events */
+ attr.config = eventsel;
+
+ counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+ /* The initial sample period (overflow count) of an event. */
+ attr.sample_period = (-counter) & pmc->bitmask;
+
+ event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ if (IS_ERR(event)) {
+ printk_once("kvm: pmu event creation failed %ld\n",
+ PTR_ERR(event));
+ return;
+ }
+
+ pmc->perf_event = event;
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 3 ++
arch/arm64/kvm/Makefile | 1 +
include/kvm/arm_pmu.h | 11 ++++
virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 137 insertions(+)
create mode 100644 virt/kvm/arm/pmu.c
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 4406184..2588f9c 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -21,6 +21,7 @@
#define ARMV8_MAX_COUNTERS 32
#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
/*
* Per-CPU PMCR: config reg
@@ -31,6 +32,8 @@
#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which PMCCNTR_EL0 bit generates an overflow */
+#define ARMV8_PMCR_LC (1 << 6)
#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
#define ARMV8_PMCR_N_MASK 0x1f
#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index ddcb5b2..14bedb0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,20 @@ struct kvm_pmu {
int irq_num;
struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx);
#else
struct kvm_pmu {
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ return 0;
+}
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx) {}
#endif
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..9d27999
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ u64 counter, reg, enabled, running;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+ reg = (select_idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+ counter = vcpu_sys_reg(vcpu, reg);
+
+ /* The real counter value is equal to the value of counter register plus
+ * the value perf event counts.
+ */
+ if (pmc->perf_event)
+ counter += perf_event_read_value(pmc->perf_event, &enabled,
+ &running);
+
+ return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+ u64 counter, reg;
+
+ if (pmc->perf_event) {
+ counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+ reg = (pmc->idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+ vcpu_sys_reg(vcpu, reg) = counter;
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+}
+
+static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
+ u64 select_idx)
+{
+ return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
+ (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+ struct perf_event *event;
+ struct perf_event_attr attr;
+ u64 eventsel, counter;
+
+ kvm_pmu_stop_counter(vcpu, pmc);
+ eventsel = data & ARMV8_EVTYPE_EVENT;
+
+ memset(&attr, 0, sizeof(struct perf_event_attr));
+ attr.type = PERF_TYPE_RAW;
+ attr.size = sizeof(attr);
+ attr.pinned = 1;
+ attr.disabled = kvm_pmu_counter_is_enabled(vcpu, select_idx);
+ attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
+ attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
+ attr.exclude_hv = 1; /* Don't count EL2 events */
+ attr.exclude_host = 1; /* Don't count host events */
+ attr.config = eventsel;
+
+ counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+ /* The initial sample period (overflow count) of an event. */
+ attr.sample_period = (-counter) & pmc->bitmask;
+
+ event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ if (IS_ERR(event)) {
+ printk_once("kvm: pmu event creation failed %ld\n",
+ PTR_ERR(event));
+ return;
+ }
+
+ pmc->perf_event = event;
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 3 ++
arch/arm64/kvm/Makefile | 1 +
include/kvm/arm_pmu.h | 11 ++++
virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 137 insertions(+)
create mode 100644 virt/kvm/arm/pmu.c
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 4406184..2588f9c 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -21,6 +21,7 @@
#define ARMV8_MAX_COUNTERS 32
#define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
+#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
/*
* Per-CPU PMCR: config reg
@@ -31,6 +32,8 @@
#define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
#define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
#define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which PMCCNTR_EL0 bit generates an overflow */
+#define ARMV8_PMCR_LC (1 << 6)
#define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
#define ARMV8_PMCR_N_MASK 0x1f
#define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index ddcb5b2..14bedb0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,20 @@ struct kvm_pmu {
int irq_num;
struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx);
#else
struct kvm_pmu {
};
+
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ return 0;
+}
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx) {}
#endif
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..9d27999
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+ u64 counter, reg, enabled, running;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+ reg = (select_idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+ counter = vcpu_sys_reg(vcpu, reg);
+
+ /* The real counter value is equal to the value of counter register plus
+ * the value perf event counts.
+ */
+ if (pmc->perf_event)
+ counter += perf_event_read_value(pmc->perf_event, &enabled,
+ &running);
+
+ return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+ u64 counter, reg;
+
+ if (pmc->perf_event) {
+ counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+ reg = (pmc->idx == ARMV8_CYCLE_IDX)
+ ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+ vcpu_sys_reg(vcpu, reg) = counter;
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+}
+
+static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
+ u64 select_idx)
+{
+ return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
+ (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+ u64 select_idx)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+ struct perf_event *event;
+ struct perf_event_attr attr;
+ u64 eventsel, counter;
+
+ kvm_pmu_stop_counter(vcpu, pmc);
+ eventsel = data & ARMV8_EVTYPE_EVENT;
+
+ memset(&attr, 0, sizeof(struct perf_event_attr));
+ attr.type = PERF_TYPE_RAW;
+ attr.size = sizeof(attr);
+ attr.pinned = 1;
+ attr.disabled = kvm_pmu_counter_is_enabled(vcpu, select_idx);
+ attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
+ attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
+ attr.exclude_hv = 1; /* Don't count EL2 events */
+ attr.exclude_host = 1; /* Don't count host events */
+ attr.config = eventsel;
+
+ counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+ /* The initial sample period (overflow count) of an event. */
+ attr.sample_period = (-counter) & pmc->bitmask;
+
+ event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ if (IS_ERR(event)) {
+ printk_once("kvm: pmu event creation failed %ld\n",
+ PTR_ERR(event));
+ return;
+ }
+
+ pmc->perf_event = event;
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When writing to these registers, create a perf_event for the selected
event type.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 154 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2552db1..ed2939b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+ u64 pmcr, val;
+
+ pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+ val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+ if (idx >= val && idx != ARMV8_CYCLE_IDX)
+ return false;
+
+ return true;
+}
+
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ reg = 0;
+ } else {
+ if (!p->is_aarch32) {
+ /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
+ reg = PMCCFILTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVTYPER0_EL0;
+ }
+ }
+ }
+
+ switch (reg) {
+ case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
+ idx = reg - PMEVTYPER0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCFILTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
+ : PMEVTYPER0_EL0 + idx;
+ break;
+ }
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n) \
+ /* PMEVTYPERn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
/*
* Architected system registers.
* Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
- trap_raz_wi },
+ access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
trap_raz_wi },
@@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVTYPERn_EL0 */
+ PMU_PMEVTYPER_EL0(0),
+ PMU_PMEVTYPER_EL0(1),
+ PMU_PMEVTYPER_EL0(2),
+ PMU_PMEVTYPER_EL0(3),
+ PMU_PMEVTYPER_EL0(4),
+ PMU_PMEVTYPER_EL0(5),
+ PMU_PMEVTYPER_EL0(6),
+ PMU_PMEVTYPER_EL0(7),
+ PMU_PMEVTYPER_EL0(8),
+ PMU_PMEVTYPER_EL0(9),
+ PMU_PMEVTYPER_EL0(10),
+ PMU_PMEVTYPER_EL0(11),
+ PMU_PMEVTYPER_EL0(12),
+ PMU_PMEVTYPER_EL0(13),
+ PMU_PMEVTYPER_EL0(14),
+ PMU_PMEVTYPER_EL0(15),
+ PMU_PMEVTYPER_EL0(16),
+ PMU_PMEVTYPER_EL0(17),
+ PMU_PMEVTYPER_EL0(18),
+ PMU_PMEVTYPER_EL0(19),
+ PMU_PMEVTYPER_EL0(20),
+ PMU_PMEVTYPER_EL0(21),
+ PMU_PMEVTYPER_EL0(22),
+ PMU_PMEVTYPER_EL0(23),
+ PMU_PMEVTYPER_EL0(24),
+ PMU_PMEVTYPER_EL0(25),
+ PMU_PMEVTYPER_EL0(26),
+ PMU_PMEVTYPER_EL0(27),
+ PMU_PMEVTYPER_EL0(28),
+ PMU_PMEVTYPER_EL0(29),
+ PMU_PMEVTYPER_EL0(30),
+ /* PMCCFILTR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
+ { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+ access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
+
/* DACR32_EL2 */
{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
NULL, reset_unknown, DACR32_EL2 },
@@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n) \
+ /* PMEVTYPERn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper }
+
/*
* Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
* depending on the way they are accessed (as a 32bit or a 64bit
@@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+ /* PMEVTYPERn */
+ PMU_PMEVTYPER(0),
+ PMU_PMEVTYPER(1),
+ PMU_PMEVTYPER(2),
+ PMU_PMEVTYPER(3),
+ PMU_PMEVTYPER(4),
+ PMU_PMEVTYPER(5),
+ PMU_PMEVTYPER(6),
+ PMU_PMEVTYPER(7),
+ PMU_PMEVTYPER(8),
+ PMU_PMEVTYPER(9),
+ PMU_PMEVTYPER(10),
+ PMU_PMEVTYPER(11),
+ PMU_PMEVTYPER(12),
+ PMU_PMEVTYPER(13),
+ PMU_PMEVTYPER(14),
+ PMU_PMEVTYPER(15),
+ PMU_PMEVTYPER(16),
+ PMU_PMEVTYPER(17),
+ PMU_PMEVTYPER(18),
+ PMU_PMEVTYPER(19),
+ PMU_PMEVTYPER(20),
+ PMU_PMEVTYPER(21),
+ PMU_PMEVTYPER(22),
+ PMU_PMEVTYPER(23),
+ PMU_PMEVTYPER(24),
+ PMU_PMEVTYPER(25),
+ PMU_PMEVTYPER(26),
+ PMU_PMEVTYPER(27),
+ PMU_PMEVTYPER(28),
+ PMU_PMEVTYPER(29),
+ PMU_PMEVTYPER(30),
+ /* PMCCFILTR */
+ { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
};
static const struct sys_reg_desc cp15_64_regs[] = {
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When writing to these registers, create a perf_event for the selected
event type.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 154 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2552db1..ed2939b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+ u64 pmcr, val;
+
+ pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+ val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+ if (idx >= val && idx != ARMV8_CYCLE_IDX)
+ return false;
+
+ return true;
+}
+
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ reg = 0;
+ } else {
+ if (!p->is_aarch32) {
+ /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
+ reg = PMCCFILTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVTYPER0_EL0;
+ }
+ }
+ }
+
+ switch (reg) {
+ case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
+ idx = reg - PMEVTYPER0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCFILTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
+ : PMEVTYPER0_EL0 + idx;
+ break;
+ }
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n) \
+ /* PMEVTYPERn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
/*
* Architected system registers.
* Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
- trap_raz_wi },
+ access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
trap_raz_wi },
@@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVTYPERn_EL0 */
+ PMU_PMEVTYPER_EL0(0),
+ PMU_PMEVTYPER_EL0(1),
+ PMU_PMEVTYPER_EL0(2),
+ PMU_PMEVTYPER_EL0(3),
+ PMU_PMEVTYPER_EL0(4),
+ PMU_PMEVTYPER_EL0(5),
+ PMU_PMEVTYPER_EL0(6),
+ PMU_PMEVTYPER_EL0(7),
+ PMU_PMEVTYPER_EL0(8),
+ PMU_PMEVTYPER_EL0(9),
+ PMU_PMEVTYPER_EL0(10),
+ PMU_PMEVTYPER_EL0(11),
+ PMU_PMEVTYPER_EL0(12),
+ PMU_PMEVTYPER_EL0(13),
+ PMU_PMEVTYPER_EL0(14),
+ PMU_PMEVTYPER_EL0(15),
+ PMU_PMEVTYPER_EL0(16),
+ PMU_PMEVTYPER_EL0(17),
+ PMU_PMEVTYPER_EL0(18),
+ PMU_PMEVTYPER_EL0(19),
+ PMU_PMEVTYPER_EL0(20),
+ PMU_PMEVTYPER_EL0(21),
+ PMU_PMEVTYPER_EL0(22),
+ PMU_PMEVTYPER_EL0(23),
+ PMU_PMEVTYPER_EL0(24),
+ PMU_PMEVTYPER_EL0(25),
+ PMU_PMEVTYPER_EL0(26),
+ PMU_PMEVTYPER_EL0(27),
+ PMU_PMEVTYPER_EL0(28),
+ PMU_PMEVTYPER_EL0(29),
+ PMU_PMEVTYPER_EL0(30),
+ /* PMCCFILTR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
+ { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+ access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
+
/* DACR32_EL2 */
{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
NULL, reset_unknown, DACR32_EL2 },
@@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n) \
+ /* PMEVTYPERn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper }
+
/*
* Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
* depending on the way they are accessed (as a 32bit or a 64bit
@@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+ /* PMEVTYPERn */
+ PMU_PMEVTYPER(0),
+ PMU_PMEVTYPER(1),
+ PMU_PMEVTYPER(2),
+ PMU_PMEVTYPER(3),
+ PMU_PMEVTYPER(4),
+ PMU_PMEVTYPER(5),
+ PMU_PMEVTYPER(6),
+ PMU_PMEVTYPER(7),
+ PMU_PMEVTYPER(8),
+ PMU_PMEVTYPER(9),
+ PMU_PMEVTYPER(10),
+ PMU_PMEVTYPER(11),
+ PMU_PMEVTYPER(12),
+ PMU_PMEVTYPER(13),
+ PMU_PMEVTYPER(14),
+ PMU_PMEVTYPER(15),
+ PMU_PMEVTYPER(16),
+ PMU_PMEVTYPER(17),
+ PMU_PMEVTYPER(18),
+ PMU_PMEVTYPER(19),
+ PMU_PMEVTYPER(20),
+ PMU_PMEVTYPER(21),
+ PMU_PMEVTYPER(22),
+ PMU_PMEVTYPER(23),
+ PMU_PMEVTYPER(24),
+ PMU_PMEVTYPER(25),
+ PMU_PMEVTYPER(26),
+ PMU_PMEVTYPER(27),
+ PMU_PMEVTYPER(28),
+ PMU_PMEVTYPER(29),
+ PMU_PMEVTYPER(30),
+ /* PMCCFILTR */
+ { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
};
static const struct sys_reg_desc cp15_64_regs[] = {
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When writing to these registers, create a perf_event for the selected
event type.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 154 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2552db1..ed2939b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+ u64 pmcr, val;
+
+ pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+ val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+ if (idx >= val && idx != ARMV8_CYCLE_IDX)
+ return false;
+
+ return true;
+}
+
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ reg = 0;
+ } else {
+ if (!p->is_aarch32) {
+ /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
+ reg = PMCCFILTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVTYPER0_EL0;
+ }
+ }
+ }
+
+ switch (reg) {
+ case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
+ idx = reg - PMEVTYPER0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCFILTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
+ : PMEVTYPER0_EL0 + idx;
+ break;
+ }
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n) \
+ /* PMEVTYPERn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
/*
* Architected system registers.
* Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
- trap_raz_wi },
+ access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
trap_raz_wi },
@@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVTYPERn_EL0 */
+ PMU_PMEVTYPER_EL0(0),
+ PMU_PMEVTYPER_EL0(1),
+ PMU_PMEVTYPER_EL0(2),
+ PMU_PMEVTYPER_EL0(3),
+ PMU_PMEVTYPER_EL0(4),
+ PMU_PMEVTYPER_EL0(5),
+ PMU_PMEVTYPER_EL0(6),
+ PMU_PMEVTYPER_EL0(7),
+ PMU_PMEVTYPER_EL0(8),
+ PMU_PMEVTYPER_EL0(9),
+ PMU_PMEVTYPER_EL0(10),
+ PMU_PMEVTYPER_EL0(11),
+ PMU_PMEVTYPER_EL0(12),
+ PMU_PMEVTYPER_EL0(13),
+ PMU_PMEVTYPER_EL0(14),
+ PMU_PMEVTYPER_EL0(15),
+ PMU_PMEVTYPER_EL0(16),
+ PMU_PMEVTYPER_EL0(17),
+ PMU_PMEVTYPER_EL0(18),
+ PMU_PMEVTYPER_EL0(19),
+ PMU_PMEVTYPER_EL0(20),
+ PMU_PMEVTYPER_EL0(21),
+ PMU_PMEVTYPER_EL0(22),
+ PMU_PMEVTYPER_EL0(23),
+ PMU_PMEVTYPER_EL0(24),
+ PMU_PMEVTYPER_EL0(25),
+ PMU_PMEVTYPER_EL0(26),
+ PMU_PMEVTYPER_EL0(27),
+ PMU_PMEVTYPER_EL0(28),
+ PMU_PMEVTYPER_EL0(29),
+ PMU_PMEVTYPER_EL0(30),
+ /* PMCCFILTR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
+ { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+ access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
+
/* DACR32_EL2 */
{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
NULL, reset_unknown, DACR32_EL2 },
@@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n) \
+ /* PMEVTYPERn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evtyper }
+
/*
* Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
* depending on the way they are accessed (as a 32bit or a 64bit
@@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+ /* PMEVTYPERn */
+ PMU_PMEVTYPER(0),
+ PMU_PMEVTYPER(1),
+ PMU_PMEVTYPER(2),
+ PMU_PMEVTYPER(3),
+ PMU_PMEVTYPER(4),
+ PMU_PMEVTYPER(5),
+ PMU_PMEVTYPER(6),
+ PMU_PMEVTYPER(7),
+ PMU_PMEVTYPER(8),
+ PMU_PMEVTYPER(9),
+ PMU_PMEVTYPER(10),
+ PMU_PMEVTYPER(11),
+ PMU_PMEVTYPER(12),
+ PMU_PMEVTYPER(13),
+ PMU_PMEVTYPER(14),
+ PMU_PMEVTYPER(15),
+ PMU_PMEVTYPER(16),
+ PMU_PMEVTYPER(17),
+ PMU_PMEVTYPER(18),
+ PMU_PMEVTYPER(19),
+ PMU_PMEVTYPER(20),
+ PMU_PMEVTYPER(21),
+ PMU_PMEVTYPER(22),
+ PMU_PMEVTYPER(23),
+ PMU_PMEVTYPER(24),
+ PMU_PMEVTYPER(25),
+ PMU_PMEVTYPER(26),
+ PMU_PMEVTYPER(27),
+ PMU_PMEVTYPER(28),
+ PMU_PMEVTYPER(29),
+ PMU_PMEVTYPER(30),
+ /* PMCCFILTR */
+ { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
};
static const struct sys_reg_desc cp15_64_regs[] = {
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When reading these registers, return the sum of register value and the
value perf event counts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 138 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 134 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ed2939b..1818947 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -569,6 +569,57 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg, val;
+
+ if (!p->is_aarch32) {
+ if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 2)
+ /* PMXEVCNTR_EL0 */
+ reg = 0;
+ else
+ /* PMEVCNTRn_EL0 or PMCCNTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 9 && r->CRm == 13) {
+ reg = (r->Op2 & 2) ? 0 : PMCCNTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVCNTR0_EL0;
+ }
+ }
+
+ switch (reg) {
+ case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ idx = reg - PMEVCNTR0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCNTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVCNTR_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCNTR_EL0
+ : PMEVCNTR0_EL0 + idx;
+ break;
+ }
+
+ val = kvm_pmu_get_counter_value(vcpu, idx);
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
+ else
+ p->regval = val;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -584,6 +635,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n) \
+ /* PMEVCNTRn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
/* Macro to expand the PMEVTYPERn_EL0 register */
#define PMU_PMEVTYPER_EL0(n) \
/* PMEVTYPERn_EL0 */ \
@@ -784,13 +842,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
- trap_raz_wi },
+ access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
- trap_raz_wi },
+ access_pmu_evcntr },
/* PMUSERENR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
trap_raz_wi },
@@ -805,6 +863,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVCNTRn_EL0 */
+ PMU_PMEVCNTR_EL0(0),
+ PMU_PMEVCNTR_EL0(1),
+ PMU_PMEVCNTR_EL0(2),
+ PMU_PMEVCNTR_EL0(3),
+ PMU_PMEVCNTR_EL0(4),
+ PMU_PMEVCNTR_EL0(5),
+ PMU_PMEVCNTR_EL0(6),
+ PMU_PMEVCNTR_EL0(7),
+ PMU_PMEVCNTR_EL0(8),
+ PMU_PMEVCNTR_EL0(9),
+ PMU_PMEVCNTR_EL0(10),
+ PMU_PMEVCNTR_EL0(11),
+ PMU_PMEVCNTR_EL0(12),
+ PMU_PMEVCNTR_EL0(13),
+ PMU_PMEVCNTR_EL0(14),
+ PMU_PMEVCNTR_EL0(15),
+ PMU_PMEVCNTR_EL0(16),
+ PMU_PMEVCNTR_EL0(17),
+ PMU_PMEVCNTR_EL0(18),
+ PMU_PMEVCNTR_EL0(19),
+ PMU_PMEVCNTR_EL0(20),
+ PMU_PMEVCNTR_EL0(21),
+ PMU_PMEVCNTR_EL0(22),
+ PMU_PMEVCNTR_EL0(23),
+ PMU_PMEVCNTR_EL0(24),
+ PMU_PMEVCNTR_EL0(25),
+ PMU_PMEVCNTR_EL0(26),
+ PMU_PMEVCNTR_EL0(27),
+ PMU_PMEVCNTR_EL0(28),
+ PMU_PMEVCNTR_EL0(29),
+ PMU_PMEVCNTR_EL0(30),
/* PMEVTYPERn_EL0 */
PMU_PMEVTYPER_EL0(0),
PMU_PMEVTYPER_EL0(1),
@@ -1033,6 +1123,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n) \
+ /* PMEVCNTRn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr }
+
/* Macro to expand the PMEVTYPERn register */
#define PMU_PMEVTYPER(n) \
/* PMEVTYPERn */ \
@@ -1075,9 +1172,9 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
- { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
- { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -1092,6 +1189,38 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+ /* PMEVCNTRn */
+ PMU_PMEVCNTR(0),
+ PMU_PMEVCNTR(1),
+ PMU_PMEVCNTR(2),
+ PMU_PMEVCNTR(3),
+ PMU_PMEVCNTR(4),
+ PMU_PMEVCNTR(5),
+ PMU_PMEVCNTR(6),
+ PMU_PMEVCNTR(7),
+ PMU_PMEVCNTR(8),
+ PMU_PMEVCNTR(9),
+ PMU_PMEVCNTR(10),
+ PMU_PMEVCNTR(11),
+ PMU_PMEVCNTR(12),
+ PMU_PMEVCNTR(13),
+ PMU_PMEVCNTR(14),
+ PMU_PMEVCNTR(15),
+ PMU_PMEVCNTR(16),
+ PMU_PMEVCNTR(17),
+ PMU_PMEVCNTR(18),
+ PMU_PMEVCNTR(19),
+ PMU_PMEVCNTR(20),
+ PMU_PMEVCNTR(21),
+ PMU_PMEVCNTR(22),
+ PMU_PMEVCNTR(23),
+ PMU_PMEVCNTR(24),
+ PMU_PMEVCNTR(25),
+ PMU_PMEVCNTR(26),
+ PMU_PMEVCNTR(27),
+ PMU_PMEVCNTR(28),
+ PMU_PMEVCNTR(29),
+ PMU_PMEVCNTR(30),
/* PMEVTYPERn */
PMU_PMEVTYPER(0),
PMU_PMEVTYPER(1),
@@ -1130,6 +1259,7 @@ static const struct sys_reg_desc cp15_regs[] = {
static const struct sys_reg_desc cp15_64_regs[] = {
{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+ { Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
};
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When reading these registers, return the sum of register value and the
value perf event counts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 138 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 134 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ed2939b..1818947 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -569,6 +569,57 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg, val;
+
+ if (!p->is_aarch32) {
+ if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 2)
+ /* PMXEVCNTR_EL0 */
+ reg = 0;
+ else
+ /* PMEVCNTRn_EL0 or PMCCNTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 9 && r->CRm == 13) {
+ reg = (r->Op2 & 2) ? 0 : PMCCNTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVCNTR0_EL0;
+ }
+ }
+
+ switch (reg) {
+ case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ idx = reg - PMEVCNTR0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCNTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVCNTR_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCNTR_EL0
+ : PMEVCNTR0_EL0 + idx;
+ break;
+ }
+
+ val = kvm_pmu_get_counter_value(vcpu, idx);
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
+ else
+ p->regval = val;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -584,6 +635,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n) \
+ /* PMEVCNTRn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
/* Macro to expand the PMEVTYPERn_EL0 register */
#define PMU_PMEVTYPER_EL0(n) \
/* PMEVTYPERn_EL0 */ \
@@ -784,13 +842,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
- trap_raz_wi },
+ access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
- trap_raz_wi },
+ access_pmu_evcntr },
/* PMUSERENR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
trap_raz_wi },
@@ -805,6 +863,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVCNTRn_EL0 */
+ PMU_PMEVCNTR_EL0(0),
+ PMU_PMEVCNTR_EL0(1),
+ PMU_PMEVCNTR_EL0(2),
+ PMU_PMEVCNTR_EL0(3),
+ PMU_PMEVCNTR_EL0(4),
+ PMU_PMEVCNTR_EL0(5),
+ PMU_PMEVCNTR_EL0(6),
+ PMU_PMEVCNTR_EL0(7),
+ PMU_PMEVCNTR_EL0(8),
+ PMU_PMEVCNTR_EL0(9),
+ PMU_PMEVCNTR_EL0(10),
+ PMU_PMEVCNTR_EL0(11),
+ PMU_PMEVCNTR_EL0(12),
+ PMU_PMEVCNTR_EL0(13),
+ PMU_PMEVCNTR_EL0(14),
+ PMU_PMEVCNTR_EL0(15),
+ PMU_PMEVCNTR_EL0(16),
+ PMU_PMEVCNTR_EL0(17),
+ PMU_PMEVCNTR_EL0(18),
+ PMU_PMEVCNTR_EL0(19),
+ PMU_PMEVCNTR_EL0(20),
+ PMU_PMEVCNTR_EL0(21),
+ PMU_PMEVCNTR_EL0(22),
+ PMU_PMEVCNTR_EL0(23),
+ PMU_PMEVCNTR_EL0(24),
+ PMU_PMEVCNTR_EL0(25),
+ PMU_PMEVCNTR_EL0(26),
+ PMU_PMEVCNTR_EL0(27),
+ PMU_PMEVCNTR_EL0(28),
+ PMU_PMEVCNTR_EL0(29),
+ PMU_PMEVCNTR_EL0(30),
/* PMEVTYPERn_EL0 */
PMU_PMEVTYPER_EL0(0),
PMU_PMEVTYPER_EL0(1),
@@ -1033,6 +1123,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n) \
+ /* PMEVCNTRn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr }
+
/* Macro to expand the PMEVTYPERn register */
#define PMU_PMEVTYPER(n) \
/* PMEVTYPERn */ \
@@ -1075,9 +1172,9 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
- { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
- { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -1092,6 +1189,38 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+ /* PMEVCNTRn */
+ PMU_PMEVCNTR(0),
+ PMU_PMEVCNTR(1),
+ PMU_PMEVCNTR(2),
+ PMU_PMEVCNTR(3),
+ PMU_PMEVCNTR(4),
+ PMU_PMEVCNTR(5),
+ PMU_PMEVCNTR(6),
+ PMU_PMEVCNTR(7),
+ PMU_PMEVCNTR(8),
+ PMU_PMEVCNTR(9),
+ PMU_PMEVCNTR(10),
+ PMU_PMEVCNTR(11),
+ PMU_PMEVCNTR(12),
+ PMU_PMEVCNTR(13),
+ PMU_PMEVCNTR(14),
+ PMU_PMEVCNTR(15),
+ PMU_PMEVCNTR(16),
+ PMU_PMEVCNTR(17),
+ PMU_PMEVCNTR(18),
+ PMU_PMEVCNTR(19),
+ PMU_PMEVCNTR(20),
+ PMU_PMEVCNTR(21),
+ PMU_PMEVCNTR(22),
+ PMU_PMEVCNTR(23),
+ PMU_PMEVCNTR(24),
+ PMU_PMEVCNTR(25),
+ PMU_PMEVCNTR(26),
+ PMU_PMEVCNTR(27),
+ PMU_PMEVCNTR(28),
+ PMU_PMEVCNTR(29),
+ PMU_PMEVCNTR(30),
/* PMEVTYPERn */
PMU_PMEVTYPER(0),
PMU_PMEVTYPER(1),
@@ -1130,6 +1259,7 @@ static const struct sys_reg_desc cp15_regs[] = {
static const struct sys_reg_desc cp15_64_regs[] = {
{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+ { Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
};
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.
The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.
When reading these registers, return the sum of register value and the
value perf event counts.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 138 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 134 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ed2939b..1818947 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -569,6 +569,57 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg, val;
+
+ if (!p->is_aarch32) {
+ if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 2)
+ /* PMXEVCNTR_EL0 */
+ reg = 0;
+ else
+ /* PMEVCNTRn_EL0 or PMCCNTR_EL0 */
+ reg = r->reg;
+ } else {
+ if (r->CRn == 9 && r->CRm == 13) {
+ reg = (r->Op2 & 2) ? 0 : PMCCNTR_EL0;
+ } else {
+ reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg += PMEVCNTR0_EL0;
+ }
+ }
+
+ switch (reg) {
+ case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ idx = reg - PMEVCNTR0_EL0;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+ break;
+ case PMCCNTR_EL0:
+ idx = ARMV8_CYCLE_IDX;
+ break;
+ default:
+ /* PMXEVCNTR_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return true;
+
+ reg = (idx == ARMV8_CYCLE_IDX) ? PMCCNTR_EL0
+ : PMEVCNTR0_EL0 + idx;
+ break;
+ }
+
+ val = kvm_pmu_get_counter_value(vcpu, idx);
+ if (p->is_write)
+ vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
+ else
+ p->regval = val;
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -584,6 +635,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n) \
+ /* PMEVCNTRn_EL0 */ \
+ { Op0(0b11), Op1(0b011), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
/* Macro to expand the PMEVTYPERn_EL0 register */
#define PMU_PMEVTYPER_EL0(n) \
/* PMEVTYPERn_EL0 */ \
@@ -784,13 +842,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmceid },
/* PMCCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
- trap_raz_wi },
+ access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
/* PMXEVTYPER_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
access_pmu_evtyper },
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
- trap_raz_wi },
+ access_pmu_evcntr },
/* PMUSERENR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
trap_raz_wi },
@@ -805,6 +863,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
NULL, reset_unknown, TPIDRRO_EL0 },
+ /* PMEVCNTRn_EL0 */
+ PMU_PMEVCNTR_EL0(0),
+ PMU_PMEVCNTR_EL0(1),
+ PMU_PMEVCNTR_EL0(2),
+ PMU_PMEVCNTR_EL0(3),
+ PMU_PMEVCNTR_EL0(4),
+ PMU_PMEVCNTR_EL0(5),
+ PMU_PMEVCNTR_EL0(6),
+ PMU_PMEVCNTR_EL0(7),
+ PMU_PMEVCNTR_EL0(8),
+ PMU_PMEVCNTR_EL0(9),
+ PMU_PMEVCNTR_EL0(10),
+ PMU_PMEVCNTR_EL0(11),
+ PMU_PMEVCNTR_EL0(12),
+ PMU_PMEVCNTR_EL0(13),
+ PMU_PMEVCNTR_EL0(14),
+ PMU_PMEVCNTR_EL0(15),
+ PMU_PMEVCNTR_EL0(16),
+ PMU_PMEVCNTR_EL0(17),
+ PMU_PMEVCNTR_EL0(18),
+ PMU_PMEVCNTR_EL0(19),
+ PMU_PMEVCNTR_EL0(20),
+ PMU_PMEVCNTR_EL0(21),
+ PMU_PMEVCNTR_EL0(22),
+ PMU_PMEVCNTR_EL0(23),
+ PMU_PMEVCNTR_EL0(24),
+ PMU_PMEVCNTR_EL0(25),
+ PMU_PMEVCNTR_EL0(26),
+ PMU_PMEVCNTR_EL0(27),
+ PMU_PMEVCNTR_EL0(28),
+ PMU_PMEVCNTR_EL0(29),
+ PMU_PMEVCNTR_EL0(30),
/* PMEVTYPERn_EL0 */
PMU_PMEVTYPER_EL0(0),
PMU_PMEVTYPER_EL0(1),
@@ -1033,6 +1123,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
{ Op1( 0), CRm( 2), .access = trap_raz_wi },
};
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n) \
+ /* PMEVCNTRn */ \
+ { Op1(0), CRn(0b1110), \
+ CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
+ access_pmu_evcntr }
+
/* Macro to expand the PMEVTYPERn register */
#define PMU_PMEVTYPER(n) \
/* PMEVTYPERn */ \
@@ -1075,9 +1172,9 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
- { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
- { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -1092,6 +1189,38 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+ /* PMEVCNTRn */
+ PMU_PMEVCNTR(0),
+ PMU_PMEVCNTR(1),
+ PMU_PMEVCNTR(2),
+ PMU_PMEVCNTR(3),
+ PMU_PMEVCNTR(4),
+ PMU_PMEVCNTR(5),
+ PMU_PMEVCNTR(6),
+ PMU_PMEVCNTR(7),
+ PMU_PMEVCNTR(8),
+ PMU_PMEVCNTR(9),
+ PMU_PMEVCNTR(10),
+ PMU_PMEVCNTR(11),
+ PMU_PMEVCNTR(12),
+ PMU_PMEVCNTR(13),
+ PMU_PMEVCNTR(14),
+ PMU_PMEVCNTR(15),
+ PMU_PMEVCNTR(16),
+ PMU_PMEVCNTR(17),
+ PMU_PMEVCNTR(18),
+ PMU_PMEVCNTR(19),
+ PMU_PMEVCNTR(20),
+ PMU_PMEVCNTR(21),
+ PMU_PMEVCNTR(22),
+ PMU_PMEVCNTR(23),
+ PMU_PMEVCNTR(24),
+ PMU_PMEVCNTR(25),
+ PMU_PMEVCNTR(26),
+ PMU_PMEVCNTR(27),
+ PMU_PMEVCNTR(28),
+ PMU_PMEVCNTR(29),
+ PMU_PMEVCNTR(30),
/* PMEVTYPERn */
PMU_PMEVTYPER(0),
PMU_PMEVTYPER(1),
@@ -1130,6 +1259,7 @@ static const struct sys_reg_desc cp15_regs[] = {
static const struct sys_reg_desc cp15_64_regs[] = {
{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+ { Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
};
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.
When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++---
include/kvm/arm_pmu.h | 9 +++++++
virt/kvm/arm/pmu.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 1818947..3416881 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -620,6 +620,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
return true;
}
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val, mask;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (p->is_write) {
+ val = p->regval & mask;
+ if (r->Op2 & 0x1) {
+ /* accessing PMCNTENSET_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) |= val;
+ kvm_pmu_enable_counter(vcpu, val);
+ } else {
+ /* accessing PMCNTENCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~val;
+ kvm_pmu_disable_counter(vcpu, val);
+ }
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -821,10 +845,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
- trap_raz_wi },
+ access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
/* PMCNTENCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
- trap_raz_wi },
+ access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
trap_raz_wi },
@@ -1166,8 +1190,8 @@ static const struct sys_reg_desc cp15_regs[] = {
/* PMU */
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 14bedb0..9d2d0c0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -36,6 +36,9 @@ struct kvm_pmu {
};
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -46,6 +49,12 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
{
return 0;
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ return 0;
+}
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 9d27999..bc64043 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -67,6 +67,69 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
+
+ val &= ARMV8_PMCR_N_MASK;
+ return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event) {
+ perf_event_enable(pmc->perf_event);
+ if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+ kvm_debug("fail to enable perf event\n");
+ }
+ }
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ perf_event_disable(pmc->perf_event);
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.
When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++---
include/kvm/arm_pmu.h | 9 +++++++
virt/kvm/arm/pmu.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 1818947..3416881 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -620,6 +620,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
return true;
}
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val, mask;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (p->is_write) {
+ val = p->regval & mask;
+ if (r->Op2 & 0x1) {
+ /* accessing PMCNTENSET_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) |= val;
+ kvm_pmu_enable_counter(vcpu, val);
+ } else {
+ /* accessing PMCNTENCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~val;
+ kvm_pmu_disable_counter(vcpu, val);
+ }
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -821,10 +845,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
- trap_raz_wi },
+ access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
/* PMCNTENCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
- trap_raz_wi },
+ access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
trap_raz_wi },
@@ -1166,8 +1190,8 @@ static const struct sys_reg_desc cp15_regs[] = {
/* PMU */
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 14bedb0..9d2d0c0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -36,6 +36,9 @@ struct kvm_pmu {
};
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -46,6 +49,12 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
{
return 0;
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ return 0;
+}
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 9d27999..bc64043 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -67,6 +67,69 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
+
+ val &= ARMV8_PMCR_N_MASK;
+ return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event) {
+ perf_event_enable(pmc->perf_event);
+ if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+ kvm_debug("fail to enable perf event\n");
+ }
+ }
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ perf_event_disable(pmc->perf_event);
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.
When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++---
include/kvm/arm_pmu.h | 9 +++++++
virt/kvm/arm/pmu.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 1818947..3416881 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -620,6 +620,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
return true;
}
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 val, mask;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (p->is_write) {
+ val = p->regval & mask;
+ if (r->Op2 & 0x1) {
+ /* accessing PMCNTENSET_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) |= val;
+ kvm_pmu_enable_counter(vcpu, val);
+ } else {
+ /* accessing PMCNTENCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~val;
+ kvm_pmu_disable_counter(vcpu, val);
+ }
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -821,10 +845,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcr, reset_pmcr, PMCR_EL0, },
/* PMCNTENSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
- trap_raz_wi },
+ access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
/* PMCNTENCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
- trap_raz_wi },
+ access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
trap_raz_wi },
@@ -1166,8 +1190,8 @@ static const struct sys_reg_desc cp15_regs[] = {
/* PMU */
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
- { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 14bedb0..9d2d0c0 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -36,6 +36,9 @@ struct kvm_pmu {
};
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -46,6 +49,12 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
{
return 0;
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ return 0;
+}
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 9d27999..bc64043 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -67,6 +67,69 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+ u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
+
+ val &= ARMV8_PMCR_N_MASK;
+ return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event) {
+ perf_event_enable(pmc->perf_event);
+ if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+ kvm_debug("fail to enable perf event\n");
+ }
+ }
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+
+ if (!val)
+ return;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ if (!(val & BIT(i)))
+ continue;
+
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ perf_event_disable(pmc->perf_event);
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 3416881..24ce4fe 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -644,6 +644,25 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->Op2 & 0x1)
+ /* accessing PMINTENSET_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) |= (p->regval & mask);
+ else
+ /* accessing PMINTENCLR_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -802,10 +821,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMINTENSET_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
- trap_raz_wi },
+ access_pminten, reset_unknown, PMINTENSET_EL1 },
/* PMINTENCLR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
- trap_raz_wi },
+ access_pminten, NULL, PMINTENSET_EL1 },
/* MAIR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1200,8 +1219,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 3416881..24ce4fe 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -644,6 +644,25 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->Op2 & 0x1)
+ /* accessing PMINTENSET_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) |= (p->regval & mask);
+ else
+ /* accessing PMINTENCLR_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -802,10 +821,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMINTENSET_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
- trap_raz_wi },
+ access_pminten, reset_unknown, PMINTENSET_EL1 },
/* PMINTENCLR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
- trap_raz_wi },
+ access_pminten, NULL, PMINTENSET_EL1 },
/* MAIR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1200,8 +1219,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 3416881..24ce4fe 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -644,6 +644,25 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->Op2 & 0x1)
+ /* accessing PMINTENSET_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) |= (p->regval & mask);
+ else
+ /* accessing PMINTENCLR_EL1 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -802,10 +821,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMINTENSET_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
- trap_raz_wi },
+ access_pminten, reset_unknown, PMINTENSET_EL1 },
/* PMINTENCLR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
- trap_raz_wi },
+ access_pminten, NULL, PMINTENSET_EL1 },
/* MAIR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1200,8 +1219,8 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
- { Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.
When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 26 +++++++++++++++++++++++---
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 24ce4fe..d61f271dd 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -663,6 +663,25 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->CRm & 0x2)
+ /* accessing PMOVSSET_EL0 */
+ kvm_pmu_overflow_set(vcpu, p->regval & mask);
+ else
+ /* accessing PMOVSCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -870,7 +889,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
trap_raz_wi },
@@ -897,7 +916,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, reset_unknown, PMOVSSET_EL0 },
/* TPIDR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1211,7 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
- { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1221,6 +1240,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 9d2d0c0..244970b 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -55,6 +56,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index bc64043..c23d57e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -130,6 +130,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
}
}
+static inline u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+ u64 reg;
+
+ reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+ reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+ return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+ u64 reg;
+
+ if (val == 0)
+ return;
+
+ vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+ reg = kvm_pmu_overflow_status(vcpu);
+ if (reg != 0)
+ kvm_vcpu_kick(vcpu);
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.
When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 26 +++++++++++++++++++++++---
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 24ce4fe..d61f271dd 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -663,6 +663,25 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->CRm & 0x2)
+ /* accessing PMOVSSET_EL0 */
+ kvm_pmu_overflow_set(vcpu, p->regval & mask);
+ else
+ /* accessing PMOVSCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -870,7 +889,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
trap_raz_wi },
@@ -897,7 +916,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, reset_unknown, PMOVSSET_EL0 },
/* TPIDR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1211,7 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
- { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1221,6 +1240,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 9d2d0c0..244970b 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -55,6 +56,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index bc64043..c23d57e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -130,6 +130,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
}
}
+static inline u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+ u64 reg;
+
+ reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+ reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+ return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+ u64 reg;
+
+ if (val == 0)
+ return;
+
+ vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+ reg = kvm_pmu_overflow_status(vcpu);
+ if (reg != 0)
+ kvm_vcpu_kick(vcpu);
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.
When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 26 +++++++++++++++++++++++---
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 24ce4fe..d61f271dd 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -663,6 +663,25 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+ if (p->is_write) {
+ if (r->CRm & 0x2)
+ /* accessing PMOVSSET_EL0 */
+ kvm_pmu_overflow_set(vcpu, p->regval & mask);
+ else
+ /* accessing PMOVSCLR_EL0 */
+ vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -870,7 +889,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmcnten, NULL, PMCNTENSET_EL0 },
/* PMOVSCLR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
trap_raz_wi },
@@ -897,7 +916,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
trap_raz_wi },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
- trap_raz_wi },
+ access_pmovs, reset_unknown, PMOVSSET_EL0 },
/* TPIDR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1211,7 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
- { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1221,6 +1240,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 9d2d0c0..244970b 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -55,6 +56,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index bc64043..c23d57e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -130,6 +130,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
}
}
+static inline u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+ u64 reg;
+
+ reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+ reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+ return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+ u64 reg;
+
+ if (val == 0)
+ return;
+
+ vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+ reg = kvm_pmu_overflow_status(vcpu);
+ if (reg != 0)
+ kvm_vcpu_kick(vcpu);
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 18 +++++++++++++++++-
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 33 +++++++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d61f271dd..92021dc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -682,6 +682,21 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask;
+
+ if (p->is_write) {
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ kvm_pmu_software_increment(vcpu, p->regval & mask);
+ } else {
+ kvm_inject_undefined(vcpu);
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -892,7 +907,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
- trap_raz_wi },
+ access_pmswinc, reset_unknown, PMSWINC_EL0 },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1231,6 +1246,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 244970b..67d168c 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index c23d57e..409f3c4 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -160,6 +160,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
kvm_vcpu_kick(vcpu);
}
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ u64 type, enable, reg;
+
+ if (val == 0)
+ return;
+
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ if (!(val & BIT(i)))
+ continue;
+ type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+ & ARMV8_EVTYPE_EVENT;
+ enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ if ((type == 0) && (enable & BIT(i))) {
+ reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+ reg = lower_32_bits(reg);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+ if (!reg)
+ kvm_pmu_overflow_set(vcpu, BIT(i));
+ }
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
@@ -189,6 +218,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
kvm_pmu_stop_counter(vcpu, pmc);
eventsel = data & ARMV8_EVTYPE_EVENT;
+ /* For software increment event it does't need to create perf event */
+ if (eventsel == 0)
+ return;
+
memset(&attr, 0, sizeof(struct perf_event_attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 18 +++++++++++++++++-
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 33 +++++++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d61f271dd..92021dc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -682,6 +682,21 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask;
+
+ if (p->is_write) {
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ kvm_pmu_software_increment(vcpu, p->regval & mask);
+ } else {
+ kvm_inject_undefined(vcpu);
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -892,7 +907,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
- trap_raz_wi },
+ access_pmswinc, reset_unknown, PMSWINC_EL0 },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1231,6 +1246,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 244970b..67d168c 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index c23d57e..409f3c4 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -160,6 +160,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
kvm_vcpu_kick(vcpu);
}
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ u64 type, enable, reg;
+
+ if (val == 0)
+ return;
+
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ if (!(val & BIT(i)))
+ continue;
+ type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+ & ARMV8_EVTYPE_EVENT;
+ enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ if ((type == 0) && (enable & BIT(i))) {
+ reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+ reg = lower_32_bits(reg);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+ if (!reg)
+ kvm_pmu_overflow_set(vcpu, BIT(i));
+ }
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
@@ -189,6 +218,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
kvm_pmu_stop_counter(vcpu, pmc);
eventsel = data & ARMV8_EVTYPE_EVENT;
+ /* For software increment event it does't need to create perf event */
+ if (eventsel == 0)
+ return;
+
memset(&attr, 0, sizeof(struct perf_event_attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 18 +++++++++++++++++-
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 33 +++++++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d61f271dd..92021dc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -682,6 +682,21 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 mask;
+
+ if (p->is_write) {
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ kvm_pmu_software_increment(vcpu, p->regval & mask);
+ } else {
+ kvm_inject_undefined(vcpu);
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -892,7 +907,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
access_pmovs, NULL, PMOVSSET_EL0 },
/* PMSWINC_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
- trap_raz_wi },
+ access_pmswinc, reset_unknown, PMSWINC_EL0 },
/* PMSELR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1231,6 +1246,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+ { Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 244970b..67d168c 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index c23d57e..409f3c4 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -160,6 +160,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
kvm_vcpu_kick(vcpu);
}
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+ int i;
+ u64 type, enable, reg;
+
+ if (val == 0)
+ return;
+
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ if (!(val & BIT(i)))
+ continue;
+ type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+ & ARMV8_EVTYPE_EVENT;
+ enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ if ((type == 0) && (enable & BIT(i))) {
+ reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+ reg = lower_32_bits(reg);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+ if (!reg)
+ kvm_pmu_overflow_set(vcpu, BIT(i));
+ }
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
@@ -189,6 +218,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
kvm_pmu_stop_counter(vcpu, pmc);
eventsel = data & ARMV8_EVTYPE_EVENT;
+ /* For software increment event it does't need to create perf event */
+ if (eventsel == 0)
+ return;
+
memset(&attr, 0, sizeof(struct perf_event_attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 92021dc..04281f1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -464,6 +464,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
val &= ~ARMV8_PMCR_MASK;
val |= p->regval & ARMV8_PMCR_MASK;
vcpu_sys_reg(vcpu, r->reg) = val;
+ kvm_pmu_handle_pmcr(vcpu, val);
} else {
/* PMCR.P & PMCR.C are RAZ */
val = vcpu_sys_reg(vcpu, r->reg)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 67d168c..7ec7706 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -41,6 +41,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -59,6 +60,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 409f3c4..fda32cb 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -189,6 +189,48 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
}
}
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+ u64 mask;
+ int i;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (val & ARMV8_PMCR_E) {
+ kvm_pmu_enable_counter(vcpu,
+ vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+ } else {
+ kvm_pmu_disable_counter(vcpu, mask);
+ }
+
+ if (val & ARMV8_PMCR_C) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMCCNTR_EL0) = 0;
+ }
+
+ if (val & ARMV8_PMCR_P) {
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = 0;
+ }
+ }
+
+ if (val & ARMV8_PMCR_LC) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ pmc->bitmask = 0xffffffffffffffffUL;
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 92021dc..04281f1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -464,6 +464,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
val &= ~ARMV8_PMCR_MASK;
val |= p->regval & ARMV8_PMCR_MASK;
vcpu_sys_reg(vcpu, r->reg) = val;
+ kvm_pmu_handle_pmcr(vcpu, val);
} else {
/* PMCR.P & PMCR.C are RAZ */
val = vcpu_sys_reg(vcpu, r->reg)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 67d168c..7ec7706 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -41,6 +41,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -59,6 +60,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 409f3c4..fda32cb 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -189,6 +189,48 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
}
}
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+ u64 mask;
+ int i;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (val & ARMV8_PMCR_E) {
+ kvm_pmu_enable_counter(vcpu,
+ vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+ } else {
+ kvm_pmu_disable_counter(vcpu, mask);
+ }
+
+ if (val & ARMV8_PMCR_C) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMCCNTR_EL0) = 0;
+ }
+
+ if (val & ARMV8_PMCR_P) {
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = 0;
+ }
+ }
+
+ if (val & ARMV8_PMCR_LC) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ pmc->bitmask = 0xffffffffffffffffUL;
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/sys_regs.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 92021dc..04281f1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -464,6 +464,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
val &= ~ARMV8_PMCR_MASK;
val |= p->regval & ARMV8_PMCR_MASK;
vcpu_sys_reg(vcpu, r->reg) = val;
+ kvm_pmu_handle_pmcr(vcpu, val);
} else {
/* PMCR.P & PMCR.C are RAZ */
val = vcpu_sys_reg(vcpu, r->reg)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 67d168c..7ec7706 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -41,6 +41,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
#else
@@ -59,6 +60,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx) {}
#endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 409f3c4..fda32cb 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -189,6 +189,48 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
}
}
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ struct kvm_pmc *pmc;
+ u64 mask;
+ int i;
+
+ mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (val & ARMV8_PMCR_E) {
+ kvm_pmu_enable_counter(vcpu,
+ vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+ } else {
+ kvm_pmu_disable_counter(vcpu, mask);
+ }
+
+ if (val & ARMV8_PMCR_C) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMCCNTR_EL0) = 0;
+ }
+
+ if (val & ARMV8_PMCR_P) {
+ for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+ pmc = &pmu->pmc[i];
+ if (pmc->perf_event)
+ local64_set(&pmc->perf_event->count, 0);
+ vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = 0;
+ }
+ }
+
+ if (val & ARMV8_PMCR_LC) {
+ pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+ pmc->bitmask = 0xffffffffffffffffUL;
+ }
+}
+
static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
u64 select_idx)
{
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 15/20] KVM: ARM64: Add a helper to forward trap to guest EL1
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
This helper forward the trap caused by MRS/MSR for arch64 and MCR/MRC,
MCRR/MRRC for arch32 CP15 to guest EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/kvm/inject_fault.c | 52 +++++++++++++++++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 3066328..88b2958 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,6 +36,7 @@ unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu);
void kvm_inject_undefined(struct kvm_vcpu *vcpu);
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 648112e..052ef25 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -27,7 +27,10 @@
#define PSTATE_FAULT_BITS_64 (PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | \
PSR_I_BIT | PSR_D_BIT)
-#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL1_EXCEPT_BAD_SYNC_OFFSET 0x0
+#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL0_EXCEPT_SYNC_OFFSET_64 0x400
+#define EL0_EXCEPT_SYNC_OFFSET_32 0x600
static void prepare_fault32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
{
@@ -201,3 +204,50 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
else
inject_undef64(vcpu);
}
+
+/**
+ * kvm_forward_trap_to_el1 - forward access trap to the guest EL1
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu)
+{
+ unsigned long cpsr;
+ u32 esr = vcpu->arch.fault.esr_el2;
+ u32 esr_ec = (esr & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT;
+
+ if (esr_ec == ESR_ELx_EC_SYS64) {
+ u64 exc_offset;
+
+ cpsr = *vcpu_cpsr(vcpu);
+ *vcpu_spsr(vcpu) = cpsr;
+ *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
+
+ *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
+
+ switch (cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT)) {
+ case PSR_MODE_EL0t:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_64;
+ break;
+ case PSR_MODE_EL1t:
+ exc_offset = EL1_EXCEPT_BAD_SYNC_OFFSET;
+ break;
+ case PSR_MODE_EL1h:
+ exc_offset = EL1_EXCEPT_SYNC_OFFSET;
+ break;
+ default:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_32;
+ }
+
+ *vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + exc_offset;
+
+ if (kvm_vcpu_trap_il_is32bit(vcpu))
+ esr |= ESR_ELx_IL;
+
+ vcpu_sys_reg(vcpu, ESR_EL1) = esr;
+ } else if (esr_ec == ESR_ELx_EC_CP15_32 ||
+ esr_ec == ESR_ELx_EC_CP15_64) {
+ prepare_fault32(vcpu, COMPAT_PSR_MODE_UND, 4);
+ }
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 15/20] KVM: ARM64: Add a helper to forward trap to guest EL1
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
This helper forward the trap caused by MRS/MSR for arch64 and MCR/MRC,
MCRR/MRRC for arch32 CP15 to guest EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/kvm/inject_fault.c | 52 +++++++++++++++++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 3066328..88b2958 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,6 +36,7 @@ unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu);
void kvm_inject_undefined(struct kvm_vcpu *vcpu);
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 648112e..052ef25 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -27,7 +27,10 @@
#define PSTATE_FAULT_BITS_64 (PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | \
PSR_I_BIT | PSR_D_BIT)
-#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL1_EXCEPT_BAD_SYNC_OFFSET 0x0
+#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL0_EXCEPT_SYNC_OFFSET_64 0x400
+#define EL0_EXCEPT_SYNC_OFFSET_32 0x600
static void prepare_fault32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
{
@@ -201,3 +204,50 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
else
inject_undef64(vcpu);
}
+
+/**
+ * kvm_forward_trap_to_el1 - forward access trap to the guest EL1
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu)
+{
+ unsigned long cpsr;
+ u32 esr = vcpu->arch.fault.esr_el2;
+ u32 esr_ec = (esr & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT;
+
+ if (esr_ec == ESR_ELx_EC_SYS64) {
+ u64 exc_offset;
+
+ cpsr = *vcpu_cpsr(vcpu);
+ *vcpu_spsr(vcpu) = cpsr;
+ *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
+
+ *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
+
+ switch (cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT)) {
+ case PSR_MODE_EL0t:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_64;
+ break;
+ case PSR_MODE_EL1t:
+ exc_offset = EL1_EXCEPT_BAD_SYNC_OFFSET;
+ break;
+ case PSR_MODE_EL1h:
+ exc_offset = EL1_EXCEPT_SYNC_OFFSET;
+ break;
+ default:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_32;
+ }
+
+ *vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + exc_offset;
+
+ if (kvm_vcpu_trap_il_is32bit(vcpu))
+ esr |= ESR_ELx_IL;
+
+ vcpu_sys_reg(vcpu, ESR_EL1) = esr;
+ } else if (esr_ec == ESR_ELx_EC_CP15_32 ||
+ esr_ec == ESR_ELx_EC_CP15_64) {
+ prepare_fault32(vcpu, COMPAT_PSR_MODE_UND, 4);
+ }
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 15/20] KVM: ARM64: Add a helper to forward trap to guest EL1
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
This helper forward the trap caused by MRS/MSR for arch64 and MCR/MRC,
MCRR/MRRC for arch32 CP15 to guest EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/kvm_emulate.h | 1 +
arch/arm64/kvm/inject_fault.c | 52 +++++++++++++++++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 3066328..88b2958 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,6 +36,7 @@ unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu);
void kvm_inject_undefined(struct kvm_vcpu *vcpu);
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 648112e..052ef25 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -27,7 +27,10 @@
#define PSTATE_FAULT_BITS_64 (PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | \
PSR_I_BIT | PSR_D_BIT)
-#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL1_EXCEPT_BAD_SYNC_OFFSET 0x0
+#define EL1_EXCEPT_SYNC_OFFSET 0x200
+#define EL0_EXCEPT_SYNC_OFFSET_64 0x400
+#define EL0_EXCEPT_SYNC_OFFSET_32 0x600
static void prepare_fault32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
{
@@ -201,3 +204,50 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
else
inject_undef64(vcpu);
}
+
+/**
+ * kvm_forward_trap_to_el1 - forward access trap to the guest EL1
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_forward_trap_to_el1(struct kvm_vcpu *vcpu)
+{
+ unsigned long cpsr;
+ u32 esr = vcpu->arch.fault.esr_el2;
+ u32 esr_ec = (esr & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT;
+
+ if (esr_ec == ESR_ELx_EC_SYS64) {
+ u64 exc_offset;
+
+ cpsr = *vcpu_cpsr(vcpu);
+ *vcpu_spsr(vcpu) = cpsr;
+ *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
+
+ *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
+
+ switch (cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT)) {
+ case PSR_MODE_EL0t:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_64;
+ break;
+ case PSR_MODE_EL1t:
+ exc_offset = EL1_EXCEPT_BAD_SYNC_OFFSET;
+ break;
+ case PSR_MODE_EL1h:
+ exc_offset = EL1_EXCEPT_SYNC_OFFSET;
+ break;
+ default:
+ exc_offset = EL0_EXCEPT_SYNC_OFFSET_32;
+ }
+
+ *vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + exc_offset;
+
+ if (kvm_vcpu_trap_il_is32bit(vcpu))
+ esr |= ESR_ELx_IL;
+
+ vcpu_sys_reg(vcpu, ESR_EL1) = esr;
+ } else if (esr_ec == ESR_ELx_EC_CP15_32 ||
+ esr_ec == ESR_ELx_EC_CP15_64) {
+ prepare_fault32(vcpu, COMPAT_PSR_MODE_UND, 4);
+ }
+}
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.
PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.
When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, forward this trap to EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 9 ++++
arch/arm64/kvm/hyp/switch.c | 3 ++
arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
3 files changed, 129 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 2588f9c..1238ade 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -67,4 +67,13 @@
#define ARMV8_EXCLUDE_EL0 (1 << 30)
#define ARMV8_INCLUDE_EL2 (1 << 27)
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
+#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read at EL0 */
+
#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..a85375f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
write_sysreg(1 << 15, hstr_el2);
write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+ /* Make sure we trap PMU access from EL0 to EL2 */
+ write_sysreg(15, pmuserenr_el0);
write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
}
@@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
write_sysreg(HCR_RW, hcr_el2);
write_sysreg(0, hstr_el2);
write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+ write_sysreg(0, pmuserenr_el0);
write_sysreg(0, cptr_el2);
}
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 04281f1..ac0cbf8 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, r->reg) = val;
}
+static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
u64 val;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
/* Only update writeable bits of PMCR */
val = vcpu_sys_reg(vcpu, r->reg);
@@ -478,6 +514,11 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write)
vcpu_sys_reg(vcpu, r->reg) = p->regval;
else
@@ -492,6 +533,11 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 pmceid;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
kvm_inject_undefined(vcpu);
} else {
@@ -523,6 +569,11 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 idx, reg;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (r->CRn == 9) {
/* PMXEVTYPER_EL0 */
reg = 0;
@@ -594,15 +645,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
switch (reg) {
case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = reg - PMEVCNTR0_EL0;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
break;
case PMCCNTR_EL0:
+ if (pmu_access_cycle_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = ARMV8_CYCLE_IDX;
break;
default:
/* PMXEVCNTR_EL0 */
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
@@ -613,10 +679,16 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
}
val = kvm_pmu_get_counter_value(vcpu, idx);
- if (p->is_write)
+ if (p->is_write) {
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
- else
+ } else {
p->regval = val;
+ }
return true;
}
@@ -626,6 +698,11 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 val, mask;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
mask = kvm_pmu_valid_counter_mask(vcpu);
if (p->is_write) {
val = p->regval & mask;
@@ -650,6 +727,11 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->Op2 & 0x1)
/* accessing PMINTENSET_EL1 */
@@ -669,6 +751,11 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->CRm & 0x2)
/* accessing PMOVSSET_EL0 */
@@ -688,6 +775,11 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask;
+ if (pmu_write_swinc_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
mask = kvm_pmu_valid_counter_mask(vcpu);
kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -698,6 +790,23 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write) {
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
+ vcpu_sys_reg(vcpu, r->reg) = p->regval & ARMV8_USERENR_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_USERENR_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -927,9 +1036,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
access_pmu_evcntr },
- /* PMUSERENR_EL0 */
+ /* PMUSERENR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
- trap_raz_wi },
+ access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1254,7 +1366,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
- { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.
PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.
When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, forward this trap to EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 9 ++++
arch/arm64/kvm/hyp/switch.c | 3 ++
arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
3 files changed, 129 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 2588f9c..1238ade 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -67,4 +67,13 @@
#define ARMV8_EXCLUDE_EL0 (1 << 30)
#define ARMV8_INCLUDE_EL2 (1 << 27)
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
+#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read at EL0 */
+
#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..a85375f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
write_sysreg(1 << 15, hstr_el2);
write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+ /* Make sure we trap PMU access from EL0 to EL2 */
+ write_sysreg(15, pmuserenr_el0);
write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
}
@@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
write_sysreg(HCR_RW, hcr_el2);
write_sysreg(0, hstr_el2);
write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+ write_sysreg(0, pmuserenr_el0);
write_sysreg(0, cptr_el2);
}
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 04281f1..ac0cbf8 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, r->reg) = val;
}
+static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
u64 val;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
/* Only update writeable bits of PMCR */
val = vcpu_sys_reg(vcpu, r->reg);
@@ -478,6 +514,11 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write)
vcpu_sys_reg(vcpu, r->reg) = p->regval;
else
@@ -492,6 +533,11 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 pmceid;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
kvm_inject_undefined(vcpu);
} else {
@@ -523,6 +569,11 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 idx, reg;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (r->CRn == 9) {
/* PMXEVTYPER_EL0 */
reg = 0;
@@ -594,15 +645,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
switch (reg) {
case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = reg - PMEVCNTR0_EL0;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
break;
case PMCCNTR_EL0:
+ if (pmu_access_cycle_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = ARMV8_CYCLE_IDX;
break;
default:
/* PMXEVCNTR_EL0 */
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
@@ -613,10 +679,16 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
}
val = kvm_pmu_get_counter_value(vcpu, idx);
- if (p->is_write)
+ if (p->is_write) {
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
- else
+ } else {
p->regval = val;
+ }
return true;
}
@@ -626,6 +698,11 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 val, mask;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
mask = kvm_pmu_valid_counter_mask(vcpu);
if (p->is_write) {
val = p->regval & mask;
@@ -650,6 +727,11 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->Op2 & 0x1)
/* accessing PMINTENSET_EL1 */
@@ -669,6 +751,11 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->CRm & 0x2)
/* accessing PMOVSSET_EL0 */
@@ -688,6 +775,11 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask;
+ if (pmu_write_swinc_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
mask = kvm_pmu_valid_counter_mask(vcpu);
kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -698,6 +790,23 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write) {
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
+ vcpu_sys_reg(vcpu, r->reg) = p->regval & ARMV8_USERENR_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_USERENR_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -927,9 +1036,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
access_pmu_evcntr },
- /* PMUSERENR_EL0 */
+ /* PMUSERENR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
- trap_raz_wi },
+ access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1254,7 +1366,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
- { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.
PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.
When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, forward this trap to EL1.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/include/asm/pmu.h | 9 ++++
arch/arm64/kvm/hyp/switch.c | 3 ++
arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
3 files changed, 129 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 2588f9c..1238ade 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -67,4 +67,13 @@
#define ARMV8_EXCLUDE_EL0 (1 << 30)
#define ARMV8_INCLUDE_EL2 (1 << 27)
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
+#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read@EL0 */
+
#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..a85375f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
write_sysreg(1 << 15, hstr_el2);
write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+ /* Make sure we trap PMU access from EL0 to EL2 */
+ write_sysreg(15, pmuserenr_el0);
write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
}
@@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
write_sysreg(HCR_RW, hcr_el2);
write_sysreg(0, hstr_el2);
write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+ write_sysreg(0, pmuserenr_el0);
write_sysreg(0, cptr_el2);
}
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 04281f1..ac0cbf8 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
vcpu_sys_reg(vcpu, r->reg) = val;
}
+static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
+static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+ u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+ return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
+ || vcpu_mode_priv(vcpu));
+}
+
static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
u64 val;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
/* Only update writeable bits of PMCR */
val = vcpu_sys_reg(vcpu, r->reg);
@@ -478,6 +514,11 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write)
vcpu_sys_reg(vcpu, r->reg) = p->regval;
else
@@ -492,6 +533,11 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 pmceid;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
kvm_inject_undefined(vcpu);
} else {
@@ -523,6 +569,11 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 idx, reg;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (r->CRn == 9) {
/* PMXEVTYPER_EL0 */
reg = 0;
@@ -594,15 +645,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
switch (reg) {
case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = reg - PMEVCNTR0_EL0;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
break;
case PMCCNTR_EL0:
+ if (pmu_access_cycle_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = ARMV8_CYCLE_IDX;
break;
default:
/* PMXEVCNTR_EL0 */
+ if (pmu_access_event_counter_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
if (!pmu_counter_idx_valid(vcpu, idx))
return true;
@@ -613,10 +679,16 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
}
val = kvm_pmu_get_counter_value(vcpu, idx);
- if (p->is_write)
+ if (p->is_write) {
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
- else
+ } else {
p->regval = val;
+ }
return true;
}
@@ -626,6 +698,11 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 val, mask;
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
mask = kvm_pmu_valid_counter_mask(vcpu);
if (p->is_write) {
val = p->regval & mask;
@@ -650,6 +727,11 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->Op2 & 0x1)
/* accessing PMINTENSET_EL1 */
@@ -669,6 +751,11 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+ if (pmu_access_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
if (r->CRm & 0x2)
/* accessing PMOVSSET_EL0 */
@@ -688,6 +775,11 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
{
u64 mask;
+ if (pmu_write_swinc_el0_disabled(vcpu)) {
+ kvm_forward_trap_to_el1(vcpu);
+ return true;
+ }
+
if (p->is_write) {
mask = kvm_pmu_valid_counter_mask(vcpu);
kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -698,6 +790,23 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write) {
+ if (!vcpu_mode_priv(vcpu)) {
+ kvm_inject_undefined(vcpu);
+ return true;
+ }
+
+ vcpu_sys_reg(vcpu, r->reg) = p->regval & ARMV8_USERENR_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_USERENR_MASK;
+ }
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -927,9 +1036,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* PMXEVCNTR_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
access_pmu_evcntr },
- /* PMUSERENR_EL0 */
+ /* PMUSERENR_EL0
+ * This register resets as unknown in 64bit mode while it resets as zero
+ * in 32bit mode. Here we choose to reset it as zero for consistency.
+ */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
- trap_raz_wi },
+ access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
/* PMOVSSET_EL0 */
{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1254,7 +1366,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
- { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+ { Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.
On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 2 ++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
#include <linux/sched.h>
#include <linux/kvm.h>
#include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
* non-preemptible context.
*/
preempt_disable();
+ kvm_pmu_flush_hwstate(vcpu);
kvm_timer_flush_hwstate(vcpu);
kvm_vgic_flush_hwstate(vcpu);
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 7ec7706..136f4e3 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index fda32cb..e28df0f 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
#include <linux/perf_event.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
/**
* kvm_pmu_get_counter_value - get PMU counter value
@@ -161,6 +162,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
}
/**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ u64 overflow;
+
+ if (pmu->irq_num == -1)
+ return;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
+ return;
+
+ overflow = kvm_pmu_overflow_status(vcpu);
+ kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+ struct kvm_pmu *pmu;
+ struct kvm_vcpu_arch *vcpu_arch;
+
+ pmc -= pmc->idx;
+ pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+ vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+ return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+ struct perf_sample_data *data,
+ struct pt_regs *regs)
+{
+ struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+ struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+ int idx = pmc->idx;
+
+ kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
* kvm_pmu_software_increment - do software increment
* @vcpu: The vcpu pointer
* @val: the value guest writes to PMSWINC register
@@ -279,7 +326,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
/* The initial sample period (overflow count) of an event. */
attr.sample_period = (-counter) & pmc->bitmask;
- event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ event = perf_event_create_kernel_counter(&attr, -1, current,
+ kvm_pmu_perf_overflow, pmc);
if (IS_ERR(event)) {
printk_once("kvm: pmu event creation failed %ld\n",
PTR_ERR(event));
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.
On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 2 ++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
#include <linux/sched.h>
#include <linux/kvm.h>
#include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
* non-preemptible context.
*/
preempt_disable();
+ kvm_pmu_flush_hwstate(vcpu);
kvm_timer_flush_hwstate(vcpu);
kvm_vgic_flush_hwstate(vcpu);
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 7ec7706..136f4e3 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index fda32cb..e28df0f 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
#include <linux/perf_event.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
/**
* kvm_pmu_get_counter_value - get PMU counter value
@@ -161,6 +162,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
}
/**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ u64 overflow;
+
+ if (pmu->irq_num == -1)
+ return;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
+ return;
+
+ overflow = kvm_pmu_overflow_status(vcpu);
+ kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+ struct kvm_pmu *pmu;
+ struct kvm_vcpu_arch *vcpu_arch;
+
+ pmc -= pmc->idx;
+ pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+ vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+ return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+ struct perf_sample_data *data,
+ struct pt_regs *regs)
+{
+ struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+ struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+ int idx = pmc->idx;
+
+ kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
* kvm_pmu_software_increment - do software increment
* @vcpu: The vcpu pointer
* @val: the value guest writes to PMSWINC register
@@ -279,7 +326,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
/* The initial sample period (overflow count) of an event. */
attr.sample_period = (-counter) & pmc->bitmask;
- event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ event = perf_event_create_kernel_counter(&attr, -1, current,
+ kvm_pmu_perf_overflow, pmc);
if (IS_ERR(event)) {
printk_once("kvm: pmu event creation failed %ld\n",
PTR_ERR(event));
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.
On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 2 ++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
#include <linux/sched.h>
#include <linux/kvm.h>
#include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
* non-preemptible context.
*/
preempt_disable();
+ kvm_pmu_flush_hwstate(vcpu);
kvm_timer_flush_hwstate(vcpu);
kvm_vgic_flush_hwstate(vcpu);
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 7ec7706..136f4e3 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index fda32cb..e28df0f 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
#include <linux/perf_event.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
/**
* kvm_pmu_get_counter_value - get PMU counter value
@@ -161,6 +162,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
}
/**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ u64 overflow;
+
+ if (pmu->irq_num == -1)
+ return;
+
+ if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
+ return;
+
+ overflow = kvm_pmu_overflow_status(vcpu);
+ kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+ struct kvm_pmu *pmu;
+ struct kvm_vcpu_arch *vcpu_arch;
+
+ pmc -= pmc->idx;
+ pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+ vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+ return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+ struct perf_sample_data *data,
+ struct pt_regs *regs)
+{
+ struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+ struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+ int idx = pmc->idx;
+
+ kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
* kvm_pmu_software_increment - do software increment
* @vcpu: The vcpu pointer
* @val: the value guest writes to PMSWINC register
@@ -279,7 +326,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
/* The initial sample period (overflow count) of an event. */
attr.sample_period = (-counter) & pmc->bitmask;
- event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+ event = perf_event_create_kernel_counter(&attr, -1, current,
+ kvm_pmu_perf_overflow, pmc);
if (IS_ERR(event)) {
printk_once("kvm: pmu event creation failed %ld\n",
PTR_ERR(event));
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When resetting vcpu, it needs to reset the PMU state to initial status.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/reset.c | 3 +++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 17 +++++++++++++++++
3 files changed, 22 insertions(+)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
+ /* Reset PMU */
+ kvm_pmu_vcpu_reset(vcpu);
+
/* Reset timer */
return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 136f4e3..51dd2d1 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -37,6 +37,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
return 0;
}
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e28df0f..e6aac73 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -68,6 +68,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+ pmu->pmc[i].idx = i;
+ pmu->pmc[i].bitmask = 0xffffffffUL;
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When resetting vcpu, it needs to reset the PMU state to initial status.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/reset.c | 3 +++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 17 +++++++++++++++++
3 files changed, 22 insertions(+)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
+ /* Reset PMU */
+ kvm_pmu_vcpu_reset(vcpu);
+
/* Reset timer */
return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 136f4e3..51dd2d1 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -37,6 +37,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
return 0;
}
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e28df0f..e6aac73 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -68,6 +68,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+ pmu->pmc[i].idx = i;
+ pmu->pmc[i].bitmask = 0xffffffffUL;
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When resetting vcpu, it needs to reset the PMU state to initial status.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm64/kvm/reset.c | 3 +++
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 17 +++++++++++++++++
3 files changed, 22 insertions(+)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
+ /* Reset PMU */
+ kvm_pmu_vcpu_reset(vcpu);
+
/* Reset timer */
return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 136f4e3..51dd2d1 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -37,6 +37,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
return 0;
}
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e28df0f..e6aac73 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -68,6 +68,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
}
}
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+ pmu->pmc[i].idx = i;
+ pmu->pmc[i].bitmask = 0xffffffffUL;
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When KVM frees VCPU, it needs to free the perf_event of PMU.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 21 +++++++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
kvm_mmu_free_memory_caches(vcpu);
kvm_timer_vcpu_terminate(vcpu);
kvm_vgic_vcpu_destroy(vcpu);
+ kvm_pmu_vcpu_destroy(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 51dd2d1..bd49cde 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -38,6 +38,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
return 0;
}
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e6aac73..3ec3cdd 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -85,6 +85,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
}
}
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ struct kvm_pmc *pmc = &pmu->pmc[i];
+
+ if (pmc->perf_event) {
+ perf_event_disable(pmc->perf_event);
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, zhaoshenglong
From: Shannon Zhao <shannon.zhao@linaro.org>
When KVM frees VCPU, it needs to free the perf_event of PMU.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 21 +++++++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
kvm_mmu_free_memory_caches(vcpu);
kvm_timer_vcpu_terminate(vcpu);
kvm_vgic_vcpu_destroy(vcpu);
+ kvm_pmu_vcpu_destroy(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 51dd2d1..bd49cde 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -38,6 +38,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
return 0;
}
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e6aac73..3ec3cdd 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -85,6 +85,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
}
}
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ struct kvm_pmc *pmc = &pmu->pmc[i];
+
+ if (pmc->perf_event) {
+ perf_event_disable(pmc->perf_event);
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
When KVM frees VCPU, it needs to free the perf_event of PMU.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
arch/arm/kvm/arm.c | 1 +
include/kvm/arm_pmu.h | 2 ++
virt/kvm/arm/pmu.c | 21 +++++++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
kvm_mmu_free_memory_caches(vcpu);
kvm_timer_vcpu_terminate(vcpu);
kvm_vgic_vcpu_destroy(vcpu);
+ kvm_pmu_vcpu_destroy(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu);
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 51dd2d1..bd49cde 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -38,6 +38,7 @@ struct kvm_pmu {
u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -59,6 +60,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
return 0;
}
void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index e6aac73..3ec3cdd 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -85,6 +85,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
}
}
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+ int i;
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+ struct kvm_pmc *pmc = &pmu->pmc[i];
+
+ if (pmc->perf_event) {
+ perf_event_disable(pmc->perf_event);
+ perf_event_release_kernel(pmc->perf_event);
+ pmc->perf_event = NULL;
+ }
+ }
+}
+
u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
{
u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2015-12-22 8:07 ` Shannon Zhao
(?)
@ 2015-12-22 8:08 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
the kvm_device_ops for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
6 files changed, 163 insertions(+)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
new file mode 100644
index 0000000..dda864e
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
@@ -0,0 +1,24 @@
+ARM Virtual Performance Monitor Unit (vPMU)
+===========================================
+
+Device types supported:
+ KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
+
+Instantiate one PMU instance for per VCPU through this API.
+
+Groups:
+ KVM_DEV_ARM_PMU_GRP_IRQ
+ Attributes:
+ The attr field of kvm_device_attr encodes one value:
+ bits: | 63 .... 32 | 31 .... 0 |
+ values: | reserved | vcpu_index |
+ A value describing the PMU overflow interrupt number for the specified
+ vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
+ interrupt type must be same for each vcpu. As a PPI, the interrupt number is
+ same for all vcpus, while as a SPI it must be different for each vcpu.
+
+ Errors:
+ -ENXIO: Unsupported attribute group
+ -EBUSY: The PMU overflow interrupt is already set
+ -ENODEV: Getting the PMU overflow interrupt number while it's not set
+ -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..cbb9022 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
+/* Device Control API: ARM PMU */
+#define KVM_DEV_ARM_PMU_GRP_IRQ 0
+#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
+
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
#define KVM_ARM_IRQ_TYPE_MASK 0xff
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index c923350..608dea6 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
extern struct kvm_device_ops kvm_xics_ops;
extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
+extern struct kvm_device_ops kvm_arm_pmu_ops;
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 03f3618..4ba6fdd 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1032,6 +1032,8 @@ enum kvm_device_type {
#define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
KVM_DEV_TYPE_ARM_VGIC_V3,
#define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
+ KVM_DEV_TYPE_ARM_PMU_V3,
+#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
KVM_DEV_TYPE_MAX,
};
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 3ec3cdd..5518308 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
#include <linux/kvm.h>
#include <linux/kvm_host.h>
#include <linux/perf_event.h>
+#include <linux/uaccess.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
#include <kvm/arm_vgic.h>
@@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
pmc->perf_event = event;
}
+
+static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.pmu.irq_num != -1;
+}
+
+static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
+ int *irq, bool is_set)
+{
+ int cpuid;
+ struct kvm_vcpu *vcpu;
+ struct kvm_pmu *pmu;
+
+ cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
+ if (cpuid >= atomic_read(&kvm->online_vcpus))
+ return -EINVAL;
+
+ vcpu = kvm_get_vcpu(kvm, cpuid);
+ if (!vcpu)
+ return -EINVAL;
+
+ pmu = &vcpu->arch.pmu;
+ if (!is_set) {
+ if (!kvm_arm_pmu_initialized(vcpu))
+ return -ENODEV;
+
+ *irq = pmu->irq_num;
+ } else {
+ if (kvm_arm_pmu_initialized(vcpu))
+ return -EBUSY;
+
+ kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
+ pmu->irq_num = *irq;
+ }
+
+ return 0;
+}
+
+static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ memset(pmu, 0, sizeof(*pmu));
+ kvm_pmu_vcpu_reset(vcpu);
+ pmu->irq_num = -1;
+ }
+
+ return 0;
+}
+
+static void kvm_arm_pmu_destroy(struct kvm_device *dev)
+{
+ kfree(dev);
+}
+
+static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg;
+
+ if (get_user(reg, uaddr))
+ return -EFAULT;
+
+ /*
+ * The PMU overflow interrupt could be a PPI or SPI, but for one
+ * VM the interrupt type must be same for each vcpu. As a PPI,
+ * the interrupt number is same for all vcpus, while as a SPI it
+ * must be different for each vcpu.
+ */
+ if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
+ return -EINVAL;
+
+ return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg = -1;
+
+
+ ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
+ if (ret)
+ return ret;
+ return put_user(reg, uaddr);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ:
+ return 0;
+ }
+
+ return -ENXIO;
+}
+
+struct kvm_device_ops kvm_arm_pmu_ops = {
+ .name = "kvm-arm-pmu",
+ .create = kvm_arm_pmu_create,
+ .destroy = kvm_arm_pmu_destroy,
+ .set_attr = kvm_arm_pmu_set_attr,
+ .get_attr = kvm_arm_pmu_get_attr,
+ .has_attr = kvm_arm_pmu_has_attr,
+};
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 484079e..81a42cc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
#ifdef CONFIG_KVM_XICS
[KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
#endif
+
+#ifdef CONFIG_KVM_ARM_PMU
+ [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
+#endif
};
int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
the kvm_device_ops for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
6 files changed, 163 insertions(+)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
new file mode 100644
index 0000000..dda864e
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
@@ -0,0 +1,24 @@
+ARM Virtual Performance Monitor Unit (vPMU)
+===========================================
+
+Device types supported:
+ KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
+
+Instantiate one PMU instance for per VCPU through this API.
+
+Groups:
+ KVM_DEV_ARM_PMU_GRP_IRQ
+ Attributes:
+ The attr field of kvm_device_attr encodes one value:
+ bits: | 63 .... 32 | 31 .... 0 |
+ values: | reserved | vcpu_index |
+ A value describing the PMU overflow interrupt number for the specified
+ vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
+ interrupt type must be same for each vcpu. As a PPI, the interrupt number is
+ same for all vcpus, while as a SPI it must be different for each vcpu.
+
+ Errors:
+ -ENXIO: Unsupported attribute group
+ -EBUSY: The PMU overflow interrupt is already set
+ -ENODEV: Getting the PMU overflow interrupt number while it's not set
+ -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..cbb9022 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
+/* Device Control API: ARM PMU */
+#define KVM_DEV_ARM_PMU_GRP_IRQ 0
+#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
+
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
#define KVM_ARM_IRQ_TYPE_MASK 0xff
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index c923350..608dea6 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
extern struct kvm_device_ops kvm_xics_ops;
extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
+extern struct kvm_device_ops kvm_arm_pmu_ops;
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 03f3618..4ba6fdd 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1032,6 +1032,8 @@ enum kvm_device_type {
#define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
KVM_DEV_TYPE_ARM_VGIC_V3,
#define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
+ KVM_DEV_TYPE_ARM_PMU_V3,
+#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
KVM_DEV_TYPE_MAX,
};
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 3ec3cdd..5518308 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
#include <linux/kvm.h>
#include <linux/kvm_host.h>
#include <linux/perf_event.h>
+#include <linux/uaccess.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
#include <kvm/arm_vgic.h>
@@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
pmc->perf_event = event;
}
+
+static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.pmu.irq_num != -1;
+}
+
+static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
+ int *irq, bool is_set)
+{
+ int cpuid;
+ struct kvm_vcpu *vcpu;
+ struct kvm_pmu *pmu;
+
+ cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
+ if (cpuid >= atomic_read(&kvm->online_vcpus))
+ return -EINVAL;
+
+ vcpu = kvm_get_vcpu(kvm, cpuid);
+ if (!vcpu)
+ return -EINVAL;
+
+ pmu = &vcpu->arch.pmu;
+ if (!is_set) {
+ if (!kvm_arm_pmu_initialized(vcpu))
+ return -ENODEV;
+
+ *irq = pmu->irq_num;
+ } else {
+ if (kvm_arm_pmu_initialized(vcpu))
+ return -EBUSY;
+
+ kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
+ pmu->irq_num = *irq;
+ }
+
+ return 0;
+}
+
+static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ memset(pmu, 0, sizeof(*pmu));
+ kvm_pmu_vcpu_reset(vcpu);
+ pmu->irq_num = -1;
+ }
+
+ return 0;
+}
+
+static void kvm_arm_pmu_destroy(struct kvm_device *dev)
+{
+ kfree(dev);
+}
+
+static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg;
+
+ if (get_user(reg, uaddr))
+ return -EFAULT;
+
+ /*
+ * The PMU overflow interrupt could be a PPI or SPI, but for one
+ * VM the interrupt type must be same for each vcpu. As a PPI,
+ * the interrupt number is same for all vcpus, while as a SPI it
+ * must be different for each vcpu.
+ */
+ if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
+ return -EINVAL;
+
+ return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg = -1;
+
+
+ ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
+ if (ret)
+ return ret;
+ return put_user(reg, uaddr);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ:
+ return 0;
+ }
+
+ return -ENXIO;
+}
+
+struct kvm_device_ops kvm_arm_pmu_ops = {
+ .name = "kvm-arm-pmu",
+ .create = kvm_arm_pmu_create,
+ .destroy = kvm_arm_pmu_destroy,
+ .set_attr = kvm_arm_pmu_set_attr,
+ .get_attr = kvm_arm_pmu_get_attr,
+ .has_attr = kvm_arm_pmu_has_attr,
+};
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 484079e..81a42cc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
#ifdef CONFIG_KVM_XICS
[KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
#endif
+
+#ifdef CONFIG_KVM_ARM_PMU
+ [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
+#endif
};
int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2015-12-22 8:08 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2015-12-22 8:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Shannon Zhao <shannon.zhao@linaro.org>
Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
the kvm_device_ops for it.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
arch/arm64/include/uapi/asm/kvm.h | 4 +
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 +
virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 4 +
6 files changed, 163 insertions(+)
create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
new file mode 100644
index 0000000..dda864e
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
@@ -0,0 +1,24 @@
+ARM Virtual Performance Monitor Unit (vPMU)
+===========================================
+
+Device types supported:
+ KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
+
+Instantiate one PMU instance for per VCPU through this API.
+
+Groups:
+ KVM_DEV_ARM_PMU_GRP_IRQ
+ Attributes:
+ The attr field of kvm_device_attr encodes one value:
+ bits: | 63 .... 32 | 31 .... 0 |
+ values: | reserved | vcpu_index |
+ A value describing the PMU overflow interrupt number for the specified
+ vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
+ interrupt type must be same for each vcpu. As a PPI, the interrupt number is
+ same for all vcpus, while as a SPI it must be different for each vcpu.
+
+ Errors:
+ -ENXIO: Unsupported attribute group
+ -EBUSY: The PMU overflow interrupt is already set
+ -ENODEV: Getting the PMU overflow interrupt number while it's not set
+ -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..cbb9022 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
+/* Device Control API: ARM PMU */
+#define KVM_DEV_ARM_PMU_GRP_IRQ 0
+#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
+
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
#define KVM_ARM_IRQ_TYPE_MASK 0xff
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index c923350..608dea6 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
extern struct kvm_device_ops kvm_xics_ops;
extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
+extern struct kvm_device_ops kvm_arm_pmu_ops;
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 03f3618..4ba6fdd 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1032,6 +1032,8 @@ enum kvm_device_type {
#define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
KVM_DEV_TYPE_ARM_VGIC_V3,
#define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
+ KVM_DEV_TYPE_ARM_PMU_V3,
+#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
KVM_DEV_TYPE_MAX,
};
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 3ec3cdd..5518308 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
#include <linux/kvm.h>
#include <linux/kvm_host.h>
#include <linux/perf_event.h>
+#include <linux/uaccess.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
#include <kvm/arm_vgic.h>
@@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
pmc->perf_event = event;
}
+
+static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.pmu.irq_num != -1;
+}
+
+static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
+ int *irq, bool is_set)
+{
+ int cpuid;
+ struct kvm_vcpu *vcpu;
+ struct kvm_pmu *pmu;
+
+ cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
+ if (cpuid >= atomic_read(&kvm->online_vcpus))
+ return -EINVAL;
+
+ vcpu = kvm_get_vcpu(kvm, cpuid);
+ if (!vcpu)
+ return -EINVAL;
+
+ pmu = &vcpu->arch.pmu;
+ if (!is_set) {
+ if (!kvm_arm_pmu_initialized(vcpu))
+ return -ENODEV;
+
+ *irq = pmu->irq_num;
+ } else {
+ if (kvm_arm_pmu_initialized(vcpu))
+ return -EBUSY;
+
+ kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
+ pmu->irq_num = *irq;
+ }
+
+ return 0;
+}
+
+static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ memset(pmu, 0, sizeof(*pmu));
+ kvm_pmu_vcpu_reset(vcpu);
+ pmu->irq_num = -1;
+ }
+
+ return 0;
+}
+
+static void kvm_arm_pmu_destroy(struct kvm_device *dev)
+{
+ kfree(dev);
+}
+
+static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg;
+
+ if (get_user(reg, uaddr))
+ return -EFAULT;
+
+ /*
+ * The PMU overflow interrupt could be a PPI or SPI, but for one
+ * VM the interrupt type must be same for each vcpu. As a PPI,
+ * the interrupt number is same for all vcpus, while as a SPI it
+ * must be different for each vcpu.
+ */
+ if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
+ return -EINVAL;
+
+ return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ: {
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ int reg = -1;
+
+
+ ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
+ if (ret)
+ return ret;
+ return put_user(reg, uaddr);
+ }
+ }
+
+ return -ENXIO;
+}
+
+static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
+ struct kvm_device_attr *attr)
+{
+ switch (attr->group) {
+ case KVM_DEV_ARM_PMU_GRP_IRQ:
+ return 0;
+ }
+
+ return -ENXIO;
+}
+
+struct kvm_device_ops kvm_arm_pmu_ops = {
+ .name = "kvm-arm-pmu",
+ .create = kvm_arm_pmu_create,
+ .destroy = kvm_arm_pmu_destroy,
+ .set_attr = kvm_arm_pmu_set_attr,
+ .get_attr = kvm_arm_pmu_get_attr,
+ .has_attr = kvm_arm_pmu_has_attr,
+};
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 484079e..81a42cc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
#ifdef CONFIG_KVM_XICS
[KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
#endif
+
+#ifdef CONFIG_KVM_ARM_PMU
+ [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
+#endif
};
int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
--
2.0.4
^ permalink raw reply related [flat|nested] 197+ messages in thread
* Re: [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 10:14 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:14 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> This register resets as unknown in 64bit mode while it resets as zero
> in 32bit mode. Here we choose to reset it as zero for consistency.
>
> PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
> accessed from EL0. Add some check helpers to handle the access from EL0.
>
> When these bits are zero, only reading PMUSERENR will trap to EL2 and
> writing PMUSERENR or reading/writing other PMU registers will trap to
> EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
> (HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
> physical PMUSERENR register on VM entry, so that it will trap PMU access
> from EL0 to EL2. Within the register access handler we check the real
> value of guest PMUSERENR register to decide whether this access is
> allowed. If not allowed, forward this trap to EL1.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 9 ++++
> arch/arm64/kvm/hyp/switch.c | 3 ++
> arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 129 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 2588f9c..1238ade 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -67,4 +67,13 @@
> #define ARMV8_EXCLUDE_EL0 (1 << 30)
> #define ARMV8_INCLUDE_EL2 (1 << 27)
>
> +/*
> + * PMUSERENR: user enable reg
> + */
> +#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
> +#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
> +#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
> +#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
> +#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read at EL0 */
> +
> #endif /* __ASM_PMU_H */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index ca8f5a5..a85375f 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> write_sysreg(1 << 15, hstr_el2);
> write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
> + /* Make sure we trap PMU access from EL0 to EL2 */
> + write_sysreg(15, pmuserenr_el0);
Please use the ARMV8_USERENR_* constants here instead of a magic number
(since you went through the hassle of defining them!).
> write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
> }
>
> @@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> write_sysreg(HCR_RW, hcr_el2);
> write_sysreg(0, hstr_el2);
> write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
> + write_sysreg(0, pmuserenr_el0);
> write_sysreg(0, cptr_el2);
> }
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 04281f1..ac0cbf8 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> vcpu_sys_reg(vcpu, r->reg) = val;
> }
>
> +static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
Please drop all the inline attributes. The compiler knows its stuff well
enough to do it automagically, and this is hardly a fast path...
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> u64 val;
>
> + if (pmu_access_el0_disabled(vcpu)) {
> + kvm_forward_trap_to_el1(vcpu);
> + return true;
> + }
So with the patch I posted earlier
(http://www.spinics.net/lists/arm-kernel/msg472693.html), all the
instances similar to that code can be rewritten as
+ if (pmu_access_el0_disabled(vcpu))
+ return false;
You can then completely drop both patch 15 and my original patch to fix
the PC stuff (which is far from being perfect, as noted by Peter).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
@ 2016-01-07 10:14 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:14 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> This register resets as unknown in 64bit mode while it resets as zero
> in 32bit mode. Here we choose to reset it as zero for consistency.
>
> PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
> accessed from EL0. Add some check helpers to handle the access from EL0.
>
> When these bits are zero, only reading PMUSERENR will trap to EL2 and
> writing PMUSERENR or reading/writing other PMU registers will trap to
> EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
> (HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
> physical PMUSERENR register on VM entry, so that it will trap PMU access
> from EL0 to EL2. Within the register access handler we check the real
> value of guest PMUSERENR register to decide whether this access is
> allowed. If not allowed, forward this trap to EL1.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 9 ++++
> arch/arm64/kvm/hyp/switch.c | 3 ++
> arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 129 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 2588f9c..1238ade 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -67,4 +67,13 @@
> #define ARMV8_EXCLUDE_EL0 (1 << 30)
> #define ARMV8_INCLUDE_EL2 (1 << 27)
>
> +/*
> + * PMUSERENR: user enable reg
> + */
> +#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
> +#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed@EL0 */
> +#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written@EL0 */
> +#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read@EL0 */
> +#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read@EL0 */
> +
> #endif /* __ASM_PMU_H */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index ca8f5a5..a85375f 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> write_sysreg(1 << 15, hstr_el2);
> write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
> + /* Make sure we trap PMU access from EL0 to EL2 */
> + write_sysreg(15, pmuserenr_el0);
Please use the ARMV8_USERENR_* constants here instead of a magic number
(since you went through the hassle of defining them!).
> write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
> }
>
> @@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> write_sysreg(HCR_RW, hcr_el2);
> write_sysreg(0, hstr_el2);
> write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
> + write_sysreg(0, pmuserenr_el0);
> write_sysreg(0, cptr_el2);
> }
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 04281f1..ac0cbf8 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> vcpu_sys_reg(vcpu, r->reg) = val;
> }
>
> +static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
Please drop all the inline attributes. The compiler knows its stuff well
enough to do it automagically, and this is hardly a fast path...
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> +static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
> +{
> + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
> +
> + return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
> + || vcpu_mode_priv(vcpu));
> +}
> +
> static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> u64 val;
>
> + if (pmu_access_el0_disabled(vcpu)) {
> + kvm_forward_trap_to_el1(vcpu);
> + return true;
> + }
So with the patch I posted earlier
(http://www.spinics.net/lists/arm-kernel/msg472693.html), all the
instances similar to that code can be rewritten as
+ if (pmu_access_el0_disabled(vcpu))
+ return false;
You can then completely drop both patch 15 and my original patch to fix
the PC stuff (which is far from being perfect, as noted by Peter).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 10:20 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:20 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> To use the ARMv8 PMU related register defines from the KVM code,
> we move the relevant definitions to asm/pmu.h header file.
>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h
@ 2016-01-07 10:20 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:20 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> To use the ARMv8 PMU related register defines from the KVM code,
> we move the relevant definitions to asm/pmu.h header file.
>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 10:21 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:21 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Here we plan to support virtual PMU for guest by full software
> emulation, so define some basic structs and functions preparing for
> futher steps. Define struct kvm_pmc for performance monitor counter and
> struct kvm_pmu for performance monitor unit for each vcpu. According to
> ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
>
> Since this only supports ARM64 (or PMUv3), add a separate config symbol
> for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
@ 2016-01-07 10:21 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:21 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Here we plan to support virtual PMU for guest by full software
> emulation, so define some basic structs and functions preparing for
> futher steps. Define struct kvm_pmc for performance monitor counter and
> struct kvm_pmu for performance monitor unit for each vcpu. According to
> ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
>
> Since this only supports ARM64 (or PMUv3), add a separate config symbol
> for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 10:23 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:23 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> We are about to trap and emulate accesses to each PMU register
> individually. This adds the context offsets for the AArch64 PMU
> registers.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers
@ 2016-01-07 10:23 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:23 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> We are about to trap and emulate accesses to each PMU register
> individually. This adds the context offsets for the AArch64 PMU
> registers.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 10:43 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:43 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add reset handler which gets host value of PMCR_EL0 and make writable
> bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
> handler for PMCR.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e8bf374..c60047e 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -34,6 +34,7 @@
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_host.h>
> #include <asm/kvm_mmu.h>
> +#include <asm/pmu.h>
>
> #include <trace/events/kvm.h>
>
> @@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
> }
>
> +static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> + u64 pmcr, val;
> +
> + asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
> + /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
> + * except PMCR.E resetting to zero.
> + */
> + val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
> + & (~ARMV8_PMCR_E);
> + vcpu_sys_reg(vcpu, r->reg) = val;
> +}
> +
> +static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 val;
> +
> + if (p->is_write) {
> + /* Only update writeable bits of PMCR */
> + val = vcpu_sys_reg(vcpu, r->reg);
> + val &= ~ARMV8_PMCR_MASK;
> + val |= p->regval & ARMV8_PMCR_MASK;
> + vcpu_sys_reg(vcpu, r->reg) = val;
> + } else {
> + /* PMCR.P & PMCR.C are RAZ */
> + val = vcpu_sys_reg(vcpu, r->reg)
> + & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
> + p->regval = val;
> + }
How can that work for 32bit, where r->reg is not populated from the trap
table? You *know* that you are accessing PMCR, so just use PMCR_EL0 as
an index into vcpu_sys_reg() in all cases. You can then drop PMCR_EL0
from the 64bit trap table entry.
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -623,7 +658,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>
> /* PMCR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
> - trap_raz_wi },
> + access_pmcr, reset_pmcr, PMCR_EL0, },
> /* PMCNTENSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
> trap_raz_wi },
> @@ -885,7 +920,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
>
> /* PMU */
> - { Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
@ 2016-01-07 10:43 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:43 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add reset handler which gets host value of PMCR_EL0 and make writable
> bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
> handler for PMCR.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e8bf374..c60047e 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -34,6 +34,7 @@
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_host.h>
> #include <asm/kvm_mmu.h>
> +#include <asm/pmu.h>
>
> #include <trace/events/kvm.h>
>
> @@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
> }
>
> +static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> + u64 pmcr, val;
> +
> + asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
> + /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
> + * except PMCR.E resetting to zero.
> + */
> + val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
> + & (~ARMV8_PMCR_E);
> + vcpu_sys_reg(vcpu, r->reg) = val;
> +}
> +
> +static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 val;
> +
> + if (p->is_write) {
> + /* Only update writeable bits of PMCR */
> + val = vcpu_sys_reg(vcpu, r->reg);
> + val &= ~ARMV8_PMCR_MASK;
> + val |= p->regval & ARMV8_PMCR_MASK;
> + vcpu_sys_reg(vcpu, r->reg) = val;
> + } else {
> + /* PMCR.P & PMCR.C are RAZ */
> + val = vcpu_sys_reg(vcpu, r->reg)
> + & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
> + p->regval = val;
> + }
How can that work for 32bit, where r->reg is not populated from the trap
table? You *know* that you are accessing PMCR, so just use PMCR_EL0 as
an index into vcpu_sys_reg() in all cases. You can then drop PMCR_EL0
from the 64bit trap table entry.
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -623,7 +658,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>
> /* PMCR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
> - trap_raz_wi },
> + access_pmcr, reset_pmcr, PMCR_EL0, },
> /* PMCNTENSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
> trap_raz_wi },
> @@ -885,7 +920,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
>
> /* PMU */
> - { Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 10:43 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:43 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
> its reset handler. When reading PMSELR, return the PMSELR.SEL field to
> guest.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c60047e..f9985fc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -474,6 +474,18 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + if (p->is_write)
> + vcpu_sys_reg(vcpu, r->reg) = p->regval;
> + else
> + /* return PMSELR.SEL field */
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_COUNTER_MASK;
Same 32bit bug again.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register
@ 2016-01-07 10:43 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:43 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
> its reset handler. When reading PMSELR, return the PMSELR.SEL field to
> guest.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c60047e..f9985fc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -474,6 +474,18 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + if (p->is_write)
> + vcpu_sys_reg(vcpu, r->reg) = p->regval;
> + else
> + /* return PMSELR.SEL field */
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & ARMV8_COUNTER_MASK;
Same 32bit bug again.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 10:44 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:44 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add access handler which gets host value of PMCEID0 or PMCEID1 when
> guest access these registers. Writing action to PMCEID0 or PMCEID1 is
> UNDEFINED.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index f9985fc..2552db1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -486,6 +486,25 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 pmceid;
> +
> + if (p->is_write) {
> + kvm_inject_undefined(vcpu);
Just "return false", which will do the right thing.
> + } else {
> + if (!(p->Op2 & 1))
> + asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
> + else
> + asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
> +
> + p->regval = pmceid;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -688,10 +707,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmselr, reset_unknown, PMSELR_EL0 },
> /* PMCEID0_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
> - trap_raz_wi },
> + access_pmceid },
> /* PMCEID1_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
> - trap_raz_wi },
> + access_pmceid },
> /* PMCCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
> trap_raz_wi },
> @@ -937,8 +956,8 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
@ 2016-01-07 10:44 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add access handler which gets host value of PMCEID0 or PMCEID1 when
> guest access these registers. Writing action to PMCEID0 or PMCEID1 is
> UNDEFINED.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index f9985fc..2552db1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -486,6 +486,25 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 pmceid;
> +
> + if (p->is_write) {
> + kvm_inject_undefined(vcpu);
Just "return false", which will do the right thing.
> + } else {
> + if (!(p->Op2 & 1))
> + asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
> + else
> + asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
> +
> + p->regval = pmceid;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -688,10 +707,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmselr, reset_unknown, PMSELR_EL0 },
> /* PMCEID0_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
> - trap_raz_wi },
> + access_pmceid },
> /* PMCEID1_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
> - trap_raz_wi },
> + access_pmceid },
> /* PMCCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
> trap_raz_wi },
> @@ -937,8 +956,8 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 10:55 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:55 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When we use tools like perf on host, perf passes the event type and the
> id of this event type category to kernel, then kernel will map them to
> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
> register. When getting the event number in KVM, directly use raw event
> type to create a perf_event for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 3 ++
> arch/arm64/kvm/Makefile | 1 +
> include/kvm/arm_pmu.h | 11 ++++
> virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 137 insertions(+)
> create mode 100644 virt/kvm/arm/pmu.c
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 4406184..2588f9c 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -21,6 +21,7 @@
>
> #define ARMV8_MAX_COUNTERS 32
> #define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
> +#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
>
> /*
> * Per-CPU PMCR: config reg
> @@ -31,6 +32,8 @@
> #define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
> #define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
> #define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
> +/* Determines which PMCCNTR_EL0 bit generates an overflow */
> +#define ARMV8_PMCR_LC (1 << 6)
> #define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
> #define ARMV8_PMCR_N_MASK 0x1f
> #define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index caee9ee..122cff4 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> +kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index ddcb5b2..14bedb0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -34,9 +34,20 @@ struct kvm_pmu {
> int irq_num;
> struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx);
> #else
> struct kvm_pmu {
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + return 0;
> +}
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx) {}
> #endif
>
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> new file mode 100644
> index 0000000..9d27999
> --- /dev/null
> +++ b/virt/kvm/arm/pmu.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/perf_event.h>
> +#include <asm/kvm_emulate.h>
> +#include <kvm/arm_pmu.h>
> +
> +/**
> + * kvm_pmu_get_counter_value - get PMU counter value
> + * @vcpu: The vcpu pointer
> + * @select_idx: The counter index
> + */
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + u64 counter, reg, enabled, running;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> +
> + reg = (select_idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
> + counter = vcpu_sys_reg(vcpu, reg);
> +
> + /* The real counter value is equal to the value of counter register plus
> + * the value perf event counts.
> + */
> + if (pmc->perf_event)
> + counter += perf_event_read_value(pmc->perf_event, &enabled,
> + &running);
> +
> + return counter & pmc->bitmask;
> +}
> +
> +/**
> + * kvm_pmu_stop_counter - stop PMU counter
> + * @pmc: The PMU counter pointer
> + *
> + * If this counter has been configured to monitor some event, release it here.
> + */
> +static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> +{
> + u64 counter, reg;
> +
> + if (pmc->perf_event) {
> + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
> + reg = (pmc->idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
> + vcpu_sys_reg(vcpu, reg) = counter;
> + perf_event_release_kernel(pmc->perf_event);
> + pmc->perf_event = NULL;
> + }
> +}
> +
> +static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> + u64 select_idx)
> +{
> + return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
> + (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
> +}
> +
> +/**
> + * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
> + * @vcpu: The vcpu pointer
> + * @data: The data guest writes to PMXEVTYPER_EL0
> + * @select_idx: The number of selected counter
> + *
> + * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
> + * event with given hardware event number. Here we call perf_event API to
> + * emulate this action and create a kernel perf event for it.
> + */
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx)
> +{
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> + struct perf_event *event;
> + struct perf_event_attr attr;
> + u64 eventsel, counter;
> +
> + kvm_pmu_stop_counter(vcpu, pmc);
> + eventsel = data & ARMV8_EVTYPE_EVENT;
> +
> + memset(&attr, 0, sizeof(struct perf_event_attr));
> + attr.type = PERF_TYPE_RAW;
> + attr.size = sizeof(attr);
> + attr.pinned = 1;
> + attr.disabled = kvm_pmu_counter_is_enabled(vcpu, select_idx);
> + attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
> + attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
> + attr.exclude_hv = 1; /* Don't count EL2 events */
> + attr.exclude_host = 1; /* Don't count host events */
> + attr.config = eventsel;
> +
> + counter = kvm_pmu_get_counter_value(vcpu, select_idx);
> + /* The initial sample period (overflow count) of an event. */
> + attr.sample_period = (-counter) & pmc->bitmask;
> +
> + event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
> + if (IS_ERR(event)) {
> + printk_once("kvm: pmu event creation failed %ld\n",
nit: pr_err_once().
> + PTR_ERR(event));
> + return;
> + }
> +
> + pmc->perf_event = event;
> +}
>
Apart from that:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2016-01-07 10:55 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 10:55 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When we use tools like perf on host, perf passes the event type and the
> id of this event type category to kernel, then kernel will map them to
> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
> register. When getting the event number in KVM, directly use raw event
> type to create a perf_event for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 3 ++
> arch/arm64/kvm/Makefile | 1 +
> include/kvm/arm_pmu.h | 11 ++++
> virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 137 insertions(+)
> create mode 100644 virt/kvm/arm/pmu.c
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 4406184..2588f9c 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -21,6 +21,7 @@
>
> #define ARMV8_MAX_COUNTERS 32
> #define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
> +#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
>
> /*
> * Per-CPU PMCR: config reg
> @@ -31,6 +32,8 @@
> #define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
> #define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
> #define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
> +/* Determines which PMCCNTR_EL0 bit generates an overflow */
> +#define ARMV8_PMCR_LC (1 << 6)
> #define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
> #define ARMV8_PMCR_N_MASK 0x1f
> #define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index caee9ee..122cff4 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> +kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index ddcb5b2..14bedb0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -34,9 +34,20 @@ struct kvm_pmu {
> int irq_num;
> struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx);
> #else
> struct kvm_pmu {
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + return 0;
> +}
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx) {}
> #endif
>
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> new file mode 100644
> index 0000000..9d27999
> --- /dev/null
> +++ b/virt/kvm/arm/pmu.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/perf_event.h>
> +#include <asm/kvm_emulate.h>
> +#include <kvm/arm_pmu.h>
> +
> +/**
> + * kvm_pmu_get_counter_value - get PMU counter value
> + * @vcpu: The vcpu pointer
> + * @select_idx: The counter index
> + */
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + u64 counter, reg, enabled, running;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> +
> + reg = (select_idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
> + counter = vcpu_sys_reg(vcpu, reg);
> +
> + /* The real counter value is equal to the value of counter register plus
> + * the value perf event counts.
> + */
> + if (pmc->perf_event)
> + counter += perf_event_read_value(pmc->perf_event, &enabled,
> + &running);
> +
> + return counter & pmc->bitmask;
> +}
> +
> +/**
> + * kvm_pmu_stop_counter - stop PMU counter
> + * @pmc: The PMU counter pointer
> + *
> + * If this counter has been configured to monitor some event, release it here.
> + */
> +static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> +{
> + u64 counter, reg;
> +
> + if (pmc->perf_event) {
> + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
> + reg = (pmc->idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
> + vcpu_sys_reg(vcpu, reg) = counter;
> + perf_event_release_kernel(pmc->perf_event);
> + pmc->perf_event = NULL;
> + }
> +}
> +
> +static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> + u64 select_idx)
> +{
> + return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
> + (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
> +}
> +
> +/**
> + * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
> + * @vcpu: The vcpu pointer
> + * @data: The data guest writes to PMXEVTYPER_EL0
> + * @select_idx: The number of selected counter
> + *
> + * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
> + * event with given hardware event number. Here we call perf_event API to
> + * emulate this action and create a kernel perf event for it.
> + */
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx)
> +{
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> + struct perf_event *event;
> + struct perf_event_attr attr;
> + u64 eventsel, counter;
> +
> + kvm_pmu_stop_counter(vcpu, pmc);
> + eventsel = data & ARMV8_EVTYPE_EVENT;
> +
> + memset(&attr, 0, sizeof(struct perf_event_attr));
> + attr.type = PERF_TYPE_RAW;
> + attr.size = sizeof(attr);
> + attr.pinned = 1;
> + attr.disabled = kvm_pmu_counter_is_enabled(vcpu, select_idx);
> + attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
> + attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
> + attr.exclude_hv = 1; /* Don't count EL2 events */
> + attr.exclude_host = 1; /* Don't count host events */
> + attr.config = eventsel;
> +
> + counter = kvm_pmu_get_counter_value(vcpu, select_idx);
> + /* The initial sample period (overflow count) of an event. */
> + attr.sample_period = (-counter) & pmc->bitmask;
> +
> + event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
> + if (IS_ERR(event)) {
> + printk_once("kvm: pmu event creation failed %ld\n",
nit: pr_err_once().
> + PTR_ERR(event));
> + return;
> + }
> +
> + pmc->perf_event = event;
> +}
>
Apart from that:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:03 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:03 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
Is there any particular reason why you're not setting reg to PMSELR_EL0,
since this is what you're using?
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCFILTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
This would allow this case to be more precise, and we could have the
default case as a bug handler.
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
> + : PMEVTYPER0_EL0 + idx;
> + break;
> + }
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVTYPERn_EL0 register */
> +#define PMU_PMEVTYPER_EL0(n) \
> + /* PMEVTYPERn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
> +
> /*
> * Architected system registers.
> * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
> @@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> - trap_raz_wi },
> + access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> trap_raz_wi },
> @@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVTYPERn_EL0 */
> + PMU_PMEVTYPER_EL0(0),
> + PMU_PMEVTYPER_EL0(1),
> + PMU_PMEVTYPER_EL0(2),
> + PMU_PMEVTYPER_EL0(3),
> + PMU_PMEVTYPER_EL0(4),
> + PMU_PMEVTYPER_EL0(5),
> + PMU_PMEVTYPER_EL0(6),
> + PMU_PMEVTYPER_EL0(7),
> + PMU_PMEVTYPER_EL0(8),
> + PMU_PMEVTYPER_EL0(9),
> + PMU_PMEVTYPER_EL0(10),
> + PMU_PMEVTYPER_EL0(11),
> + PMU_PMEVTYPER_EL0(12),
> + PMU_PMEVTYPER_EL0(13),
> + PMU_PMEVTYPER_EL0(14),
> + PMU_PMEVTYPER_EL0(15),
> + PMU_PMEVTYPER_EL0(16),
> + PMU_PMEVTYPER_EL0(17),
> + PMU_PMEVTYPER_EL0(18),
> + PMU_PMEVTYPER_EL0(19),
> + PMU_PMEVTYPER_EL0(20),
> + PMU_PMEVTYPER_EL0(21),
> + PMU_PMEVTYPER_EL0(22),
> + PMU_PMEVTYPER_EL0(23),
> + PMU_PMEVTYPER_EL0(24),
> + PMU_PMEVTYPER_EL0(25),
> + PMU_PMEVTYPER_EL0(26),
> + PMU_PMEVTYPER_EL0(27),
> + PMU_PMEVTYPER_EL0(28),
> + PMU_PMEVTYPER_EL0(29),
> + PMU_PMEVTYPER_EL0(30),
> + /* PMCCFILTR_EL0
> + * This register resets as unknown in 64bit mode while it resets as zero
> + * in 32bit mode. Here we choose to reset it as zero for consistency.
> + */
> + { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
> + access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
> +
> /* DACR32_EL2 */
> { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
> NULL, reset_unknown, DACR32_EL2 },
> @@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVTYPERn register */
> +#define PMU_PMEVTYPER(n) \
> + /* PMEVTYPERn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper }
> +
> /*
> * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
> * depending on the way they are accessed (as a 32bit or a 64bit
> @@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> @@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
> +
> + /* PMEVTYPERn */
> + PMU_PMEVTYPER(0),
> + PMU_PMEVTYPER(1),
> + PMU_PMEVTYPER(2),
> + PMU_PMEVTYPER(3),
> + PMU_PMEVTYPER(4),
> + PMU_PMEVTYPER(5),
> + PMU_PMEVTYPER(6),
> + PMU_PMEVTYPER(7),
> + PMU_PMEVTYPER(8),
> + PMU_PMEVTYPER(9),
> + PMU_PMEVTYPER(10),
> + PMU_PMEVTYPER(11),
> + PMU_PMEVTYPER(12),
> + PMU_PMEVTYPER(13),
> + PMU_PMEVTYPER(14),
> + PMU_PMEVTYPER(15),
> + PMU_PMEVTYPER(16),
> + PMU_PMEVTYPER(17),
> + PMU_PMEVTYPER(18),
> + PMU_PMEVTYPER(19),
> + PMU_PMEVTYPER(20),
> + PMU_PMEVTYPER(21),
> + PMU_PMEVTYPER(22),
> + PMU_PMEVTYPER(23),
> + PMU_PMEVTYPER(24),
> + PMU_PMEVTYPER(25),
> + PMU_PMEVTYPER(26),
> + PMU_PMEVTYPER(27),
> + PMU_PMEVTYPER(28),
> + PMU_PMEVTYPER(29),
> + PMU_PMEVTYPER(30),
> + /* PMCCFILTR */
> + { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
> };
>
> static const struct sys_reg_desc cp15_64_regs[] = {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 11:03 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:03 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
Is there any particular reason why you're not setting reg to PMSELR_EL0,
since this is what you're using?
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCFILTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
This would allow this case to be more precise, and we could have the
default case as a bug handler.
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
> + : PMEVTYPER0_EL0 + idx;
> + break;
> + }
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVTYPERn_EL0 register */
> +#define PMU_PMEVTYPER_EL0(n) \
> + /* PMEVTYPERn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
> +
> /*
> * Architected system registers.
> * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
> @@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> - trap_raz_wi },
> + access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> trap_raz_wi },
> @@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVTYPERn_EL0 */
> + PMU_PMEVTYPER_EL0(0),
> + PMU_PMEVTYPER_EL0(1),
> + PMU_PMEVTYPER_EL0(2),
> + PMU_PMEVTYPER_EL0(3),
> + PMU_PMEVTYPER_EL0(4),
> + PMU_PMEVTYPER_EL0(5),
> + PMU_PMEVTYPER_EL0(6),
> + PMU_PMEVTYPER_EL0(7),
> + PMU_PMEVTYPER_EL0(8),
> + PMU_PMEVTYPER_EL0(9),
> + PMU_PMEVTYPER_EL0(10),
> + PMU_PMEVTYPER_EL0(11),
> + PMU_PMEVTYPER_EL0(12),
> + PMU_PMEVTYPER_EL0(13),
> + PMU_PMEVTYPER_EL0(14),
> + PMU_PMEVTYPER_EL0(15),
> + PMU_PMEVTYPER_EL0(16),
> + PMU_PMEVTYPER_EL0(17),
> + PMU_PMEVTYPER_EL0(18),
> + PMU_PMEVTYPER_EL0(19),
> + PMU_PMEVTYPER_EL0(20),
> + PMU_PMEVTYPER_EL0(21),
> + PMU_PMEVTYPER_EL0(22),
> + PMU_PMEVTYPER_EL0(23),
> + PMU_PMEVTYPER_EL0(24),
> + PMU_PMEVTYPER_EL0(25),
> + PMU_PMEVTYPER_EL0(26),
> + PMU_PMEVTYPER_EL0(27),
> + PMU_PMEVTYPER_EL0(28),
> + PMU_PMEVTYPER_EL0(29),
> + PMU_PMEVTYPER_EL0(30),
> + /* PMCCFILTR_EL0
> + * This register resets as unknown in 64bit mode while it resets as zero
> + * in 32bit mode. Here we choose to reset it as zero for consistency.
> + */
> + { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
> + access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
> +
> /* DACR32_EL2 */
> { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
> NULL, reset_unknown, DACR32_EL2 },
> @@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVTYPERn register */
> +#define PMU_PMEVTYPER(n) \
> + /* PMEVTYPERn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper }
> +
> /*
> * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
> * depending on the way they are accessed (as a 32bit or a 64bit
> @@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> @@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
> +
> + /* PMEVTYPERn */
> + PMU_PMEVTYPER(0),
> + PMU_PMEVTYPER(1),
> + PMU_PMEVTYPER(2),
> + PMU_PMEVTYPER(3),
> + PMU_PMEVTYPER(4),
> + PMU_PMEVTYPER(5),
> + PMU_PMEVTYPER(6),
> + PMU_PMEVTYPER(7),
> + PMU_PMEVTYPER(8),
> + PMU_PMEVTYPER(9),
> + PMU_PMEVTYPER(10),
> + PMU_PMEVTYPER(11),
> + PMU_PMEVTYPER(12),
> + PMU_PMEVTYPER(13),
> + PMU_PMEVTYPER(14),
> + PMU_PMEVTYPER(15),
> + PMU_PMEVTYPER(16),
> + PMU_PMEVTYPER(17),
> + PMU_PMEVTYPER(18),
> + PMU_PMEVTYPER(19),
> + PMU_PMEVTYPER(20),
> + PMU_PMEVTYPER(21),
> + PMU_PMEVTYPER(22),
> + PMU_PMEVTYPER(23),
> + PMU_PMEVTYPER(24),
> + PMU_PMEVTYPER(25),
> + PMU_PMEVTYPER(26),
> + PMU_PMEVTYPER(27),
> + PMU_PMEVTYPER(28),
> + PMU_PMEVTYPER(29),
> + PMU_PMEVTYPER(30),
> + /* PMCCFILTR */
> + { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
> };
>
> static const struct sys_reg_desc cp15_64_regs[] = {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:06 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:06 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
> is mapped to PMEVCNTRn.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When reading these registers, return the sum of register value and the
> value perf event counts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 138 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 134 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index ed2939b..1818947 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -569,6 +569,57 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
> + struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg, val;
> +
> + if (!p->is_aarch32) {
> + if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 2)
> + /* PMXEVCNTR_EL0 */
> + reg = 0;
> + else
> + /* PMEVCNTRn_EL0 or PMCCNTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 9 && r->CRm == 13) {
> + reg = (r->Op2 & 2) ? 0 : PMCCNTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVCNTR0_EL0;
> + }
> + }
Same remark about the use of 0 instead of PMSELR_EL0.
> +
> + switch (reg) {
> + case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
> + idx = reg - PMEVCNTR0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCNTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
> + /* PMXEVCNTR_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCNTR_EL0
> + : PMEVCNTR0_EL0 + idx;
> + break;
> + }
> +
> + val = kvm_pmu_get_counter_value(vcpu, idx);
> + if (p->is_write)
> + vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
> + else
> + p->regval = val;
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -584,6 +635,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVCNTRn_EL0 register */
> +#define PMU_PMEVCNTR_EL0(n) \
> + /* PMEVCNTRn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
> +
> /* Macro to expand the PMEVTYPERn_EL0 register */
> #define PMU_PMEVTYPER_EL0(n) \
> /* PMEVTYPERn_EL0 */ \
> @@ -784,13 +842,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmceid },
> /* PMCCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
> - trap_raz_wi },
> + access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> - trap_raz_wi },
> + access_pmu_evcntr },
> /* PMUSERENR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
> trap_raz_wi },
> @@ -805,6 +863,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVCNTRn_EL0 */
> + PMU_PMEVCNTR_EL0(0),
> + PMU_PMEVCNTR_EL0(1),
> + PMU_PMEVCNTR_EL0(2),
> + PMU_PMEVCNTR_EL0(3),
> + PMU_PMEVCNTR_EL0(4),
> + PMU_PMEVCNTR_EL0(5),
> + PMU_PMEVCNTR_EL0(6),
> + PMU_PMEVCNTR_EL0(7),
> + PMU_PMEVCNTR_EL0(8),
> + PMU_PMEVCNTR_EL0(9),
> + PMU_PMEVCNTR_EL0(10),
> + PMU_PMEVCNTR_EL0(11),
> + PMU_PMEVCNTR_EL0(12),
> + PMU_PMEVCNTR_EL0(13),
> + PMU_PMEVCNTR_EL0(14),
> + PMU_PMEVCNTR_EL0(15),
> + PMU_PMEVCNTR_EL0(16),
> + PMU_PMEVCNTR_EL0(17),
> + PMU_PMEVCNTR_EL0(18),
> + PMU_PMEVCNTR_EL0(19),
> + PMU_PMEVCNTR_EL0(20),
> + PMU_PMEVCNTR_EL0(21),
> + PMU_PMEVCNTR_EL0(22),
> + PMU_PMEVCNTR_EL0(23),
> + PMU_PMEVCNTR_EL0(24),
> + PMU_PMEVCNTR_EL0(25),
> + PMU_PMEVCNTR_EL0(26),
> + PMU_PMEVCNTR_EL0(27),
> + PMU_PMEVCNTR_EL0(28),
> + PMU_PMEVCNTR_EL0(29),
> + PMU_PMEVCNTR_EL0(30),
> /* PMEVTYPERn_EL0 */
> PMU_PMEVTYPER_EL0(0),
> PMU_PMEVTYPER_EL0(1),
> @@ -1033,6 +1123,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVCNTRn register */
> +#define PMU_PMEVCNTR(n) \
> + /* PMEVCNTRn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evcntr }
> +
> /* Macro to expand the PMEVTYPERn register */
> #define PMU_PMEVTYPER(n) \
> /* PMEVTYPERn */ \
> @@ -1075,9 +1172,9 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
> { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
> @@ -1092,6 +1189,38 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
>
> + /* PMEVCNTRn */
> + PMU_PMEVCNTR(0),
> + PMU_PMEVCNTR(1),
> + PMU_PMEVCNTR(2),
> + PMU_PMEVCNTR(3),
> + PMU_PMEVCNTR(4),
> + PMU_PMEVCNTR(5),
> + PMU_PMEVCNTR(6),
> + PMU_PMEVCNTR(7),
> + PMU_PMEVCNTR(8),
> + PMU_PMEVCNTR(9),
> + PMU_PMEVCNTR(10),
> + PMU_PMEVCNTR(11),
> + PMU_PMEVCNTR(12),
> + PMU_PMEVCNTR(13),
> + PMU_PMEVCNTR(14),
> + PMU_PMEVCNTR(15),
> + PMU_PMEVCNTR(16),
> + PMU_PMEVCNTR(17),
> + PMU_PMEVCNTR(18),
> + PMU_PMEVCNTR(19),
> + PMU_PMEVCNTR(20),
> + PMU_PMEVCNTR(21),
> + PMU_PMEVCNTR(22),
> + PMU_PMEVCNTR(23),
> + PMU_PMEVCNTR(24),
> + PMU_PMEVCNTR(25),
> + PMU_PMEVCNTR(26),
> + PMU_PMEVCNTR(27),
> + PMU_PMEVCNTR(28),
> + PMU_PMEVCNTR(29),
> + PMU_PMEVCNTR(30),
> /* PMEVTYPERn */
> PMU_PMEVTYPER(0),
> PMU_PMEVTYPER(1),
> @@ -1130,6 +1259,7 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> static const struct sys_reg_desc cp15_64_regs[] = {
> { Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
> + { Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
> { Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
> { Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register
@ 2016-01-07 11:06 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:06 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
> is mapped to PMEVCNTRn.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When reading these registers, return the sum of register value and the
> value perf event counts.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 138 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 134 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index ed2939b..1818947 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -569,6 +569,57 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
> + struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg, val;
> +
> + if (!p->is_aarch32) {
> + if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 2)
> + /* PMXEVCNTR_EL0 */
> + reg = 0;
> + else
> + /* PMEVCNTRn_EL0 or PMCCNTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 9 && r->CRm == 13) {
> + reg = (r->Op2 & 2) ? 0 : PMCCNTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVCNTR0_EL0;
> + }
> + }
Same remark about the use of 0 instead of PMSELR_EL0.
> +
> + switch (reg) {
> + case PMEVCNTR0_EL0 ... PMEVCNTR30_EL0:
> + idx = reg - PMEVCNTR0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCNTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
> + /* PMXEVCNTR_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCNTR_EL0
> + : PMEVCNTR0_EL0 + idx;
> + break;
> + }
> +
> + val = kvm_pmu_get_counter_value(vcpu, idx);
> + if (p->is_write)
> + vcpu_sys_reg(vcpu, reg) += (s64)p->regval - val;
> + else
> + p->regval = val;
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -584,6 +635,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVCNTRn_EL0 register */
> +#define PMU_PMEVCNTR_EL0(n) \
> + /* PMEVCNTRn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
> +
> /* Macro to expand the PMEVTYPERn_EL0 register */
> #define PMU_PMEVTYPER_EL0(n) \
> /* PMEVTYPERn_EL0 */ \
> @@ -784,13 +842,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmceid },
> /* PMCCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
> - trap_raz_wi },
> + access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> - trap_raz_wi },
> + access_pmu_evcntr },
> /* PMUSERENR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
> trap_raz_wi },
> @@ -805,6 +863,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVCNTRn_EL0 */
> + PMU_PMEVCNTR_EL0(0),
> + PMU_PMEVCNTR_EL0(1),
> + PMU_PMEVCNTR_EL0(2),
> + PMU_PMEVCNTR_EL0(3),
> + PMU_PMEVCNTR_EL0(4),
> + PMU_PMEVCNTR_EL0(5),
> + PMU_PMEVCNTR_EL0(6),
> + PMU_PMEVCNTR_EL0(7),
> + PMU_PMEVCNTR_EL0(8),
> + PMU_PMEVCNTR_EL0(9),
> + PMU_PMEVCNTR_EL0(10),
> + PMU_PMEVCNTR_EL0(11),
> + PMU_PMEVCNTR_EL0(12),
> + PMU_PMEVCNTR_EL0(13),
> + PMU_PMEVCNTR_EL0(14),
> + PMU_PMEVCNTR_EL0(15),
> + PMU_PMEVCNTR_EL0(16),
> + PMU_PMEVCNTR_EL0(17),
> + PMU_PMEVCNTR_EL0(18),
> + PMU_PMEVCNTR_EL0(19),
> + PMU_PMEVCNTR_EL0(20),
> + PMU_PMEVCNTR_EL0(21),
> + PMU_PMEVCNTR_EL0(22),
> + PMU_PMEVCNTR_EL0(23),
> + PMU_PMEVCNTR_EL0(24),
> + PMU_PMEVCNTR_EL0(25),
> + PMU_PMEVCNTR_EL0(26),
> + PMU_PMEVCNTR_EL0(27),
> + PMU_PMEVCNTR_EL0(28),
> + PMU_PMEVCNTR_EL0(29),
> + PMU_PMEVCNTR_EL0(30),
> /* PMEVTYPERn_EL0 */
> PMU_PMEVTYPER_EL0(0),
> PMU_PMEVTYPER_EL0(1),
> @@ -1033,6 +1123,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVCNTRn register */
> +#define PMU_PMEVCNTR(n) \
> + /* PMEVCNTRn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evcntr }
> +
> /* Macro to expand the PMEVTYPERn register */
> #define PMU_PMEVTYPER(n) \
> /* PMEVTYPERn */ \
> @@ -1075,9 +1172,9 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
> { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
> @@ -1092,6 +1189,38 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
>
> + /* PMEVCNTRn */
> + PMU_PMEVCNTR(0),
> + PMU_PMEVCNTR(1),
> + PMU_PMEVCNTR(2),
> + PMU_PMEVCNTR(3),
> + PMU_PMEVCNTR(4),
> + PMU_PMEVCNTR(5),
> + PMU_PMEVCNTR(6),
> + PMU_PMEVCNTR(7),
> + PMU_PMEVCNTR(8),
> + PMU_PMEVCNTR(9),
> + PMU_PMEVCNTR(10),
> + PMU_PMEVCNTR(11),
> + PMU_PMEVCNTR(12),
> + PMU_PMEVCNTR(13),
> + PMU_PMEVCNTR(14),
> + PMU_PMEVCNTR(15),
> + PMU_PMEVCNTR(16),
> + PMU_PMEVCNTR(17),
> + PMU_PMEVCNTR(18),
> + PMU_PMEVCNTR(19),
> + PMU_PMEVCNTR(20),
> + PMU_PMEVCNTR(21),
> + PMU_PMEVCNTR(22),
> + PMU_PMEVCNTR(23),
> + PMU_PMEVCNTR(24),
> + PMU_PMEVCNTR(25),
> + PMU_PMEVCNTR(26),
> + PMU_PMEVCNTR(27),
> + PMU_PMEVCNTR(28),
> + PMU_PMEVCNTR(29),
> + PMU_PMEVCNTR(30),
> /* PMEVTYPERn */
> PMU_PMEVTYPER(0),
> PMU_PMEVTYPER(1),
> @@ -1130,6 +1259,7 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> static const struct sys_reg_desc cp15_64_regs[] = {
> { Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
> + { Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
> { Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
> { Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:09 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:09 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMCNTENSET or PMCNTENCLR register.
>
> When writing to PMCNTENSET, call perf_event_enable to enable the perf
> event. When writing to PMCNTENCLR, call perf_event_disable to disable
> the perf event.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++---
> include/kvm/arm_pmu.h | 9 +++++++
> virt/kvm/arm/pmu.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 100 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 1818947..3416881 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -620,6 +620,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 val, mask;
> +
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + if (p->is_write) {
> + val = p->regval & mask;
> + if (r->Op2 & 0x1) {
> + /* accessing PMCNTENSET_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) |= val;
> + kvm_pmu_enable_counter(vcpu, val);
> + } else {
> + /* accessing PMCNTENCLR_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~val;
> + kvm_pmu_disable_counter(vcpu, val);
> + }
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
Same bug with 32bit and the use of r->reg. Directly use PMCNTENSET_EL0
instead.
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -821,10 +845,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmcr, reset_pmcr, PMCR_EL0, },
> /* PMCNTENSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
> - trap_raz_wi },
> + access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
> /* PMCNTENCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
> - trap_raz_wi },
> + access_pmcnten, NULL, PMCNTENSET_EL0 },
> /* PMOVSCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
> trap_raz_wi },
> @@ -1166,8 +1190,8 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> /* PMU */
> { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 14bedb0..9d2d0c0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -36,6 +36,9 @@ struct kvm_pmu {
> };
>
> u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -46,6 +49,12 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> {
> return 0;
> }
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> +{
> + return 0;
> +}
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 9d27999..bc64043 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -67,6 +67,69 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> }
> }
>
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> +{
> + u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
> +
> + val &= ARMV8_PMCR_N_MASK;
> + return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
> +}
> +
> +/**
> + * kvm_pmu_enable_counter - enable selected PMU counter
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCNTENSET register
> + *
> + * Call perf_event_enable to start counting the perf event
> + */
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> +
> + if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
> + return;
> +
> + for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
> + if (!(val & BIT(i)))
> + continue;
> +
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event) {
> + perf_event_enable(pmc->perf_event);
> + if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
> + kvm_debug("fail to enable perf event\n");
> + }
> + }
> +}
> +
> +/**
> + * kvm_pmu_disable_counter - disable selected PMU counter
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCNTENCLR register
> + *
> + * Call perf_event_disable to stop counting the perf event
> + */
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> +
> + if (!val)
> + return;
> +
> + for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
> + if (!(val & BIT(i)))
> + continue;
> +
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event)
> + perf_event_disable(pmc->perf_event);
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
@ 2016-01-07 11:09 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:09 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMCNTENSET or PMCNTENCLR register.
>
> When writing to PMCNTENSET, call perf_event_enable to enable the perf
> event. When writing to PMCNTENCLR, call perf_event_disable to disable
> the perf event.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++---
> include/kvm/arm_pmu.h | 9 +++++++
> virt/kvm/arm/pmu.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 100 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 1818947..3416881 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -620,6 +620,30 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 val, mask;
> +
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + if (p->is_write) {
> + val = p->regval & mask;
> + if (r->Op2 & 0x1) {
> + /* accessing PMCNTENSET_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) |= val;
> + kvm_pmu_enable_counter(vcpu, val);
> + } else {
> + /* accessing PMCNTENCLR_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~val;
> + kvm_pmu_disable_counter(vcpu, val);
> + }
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
Same bug with 32bit and the use of r->reg. Directly use PMCNTENSET_EL0
instead.
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -821,10 +845,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmcr, reset_pmcr, PMCR_EL0, },
> /* PMCNTENSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
> - trap_raz_wi },
> + access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
> /* PMCNTENCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
> - trap_raz_wi },
> + access_pmcnten, NULL, PMCNTENSET_EL0 },
> /* PMOVSCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
> trap_raz_wi },
> @@ -1166,8 +1190,8 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> /* PMU */
> { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 14bedb0..9d2d0c0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -36,6 +36,9 @@ struct kvm_pmu {
> };
>
> u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -46,6 +49,12 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> {
> return 0;
> }
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> +{
> + return 0;
> +}
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 9d27999..bc64043 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -67,6 +67,69 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> }
> }
>
> +u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> +{
> + u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
> +
> + val &= ARMV8_PMCR_N_MASK;
> + return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
> +}
> +
> +/**
> + * kvm_pmu_enable_counter - enable selected PMU counter
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCNTENSET register
> + *
> + * Call perf_event_enable to start counting the perf event
> + */
> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> +
> + if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
> + return;
> +
> + for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
> + if (!(val & BIT(i)))
> + continue;
> +
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event) {
> + perf_event_enable(pmc->perf_event);
> + if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
> + kvm_debug("fail to enable perf event\n");
> + }
> + }
> +}
> +
> +/**
> + * kvm_pmu_disable_counter - disable selected PMU counter
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCNTENCLR register
> + *
> + * Call perf_event_disable to stop counting the perf event
> + */
> +void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> +
> + if (!val)
> + return;
> +
> + for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
> + if (!(val & BIT(i)))
> + continue;
> +
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event)
> + perf_event_disable(pmc->perf_event);
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2016-01-07 11:03 ` Marc Zyngier
(?)
@ 2016-01-07 11:11 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:11 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
Ah, you're right. Will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 11:11 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:11 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
Ah, you're right. Will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 11:11 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:11 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
Ah, you're right. Will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:13 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:13 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMINTENSET or PMINTENCLR register.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 3416881..24ce4fe 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -644,6 +644,25 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask = kvm_pmu_valid_counter_mask(vcpu);
> +
> + if (p->is_write) {
> + if (r->Op2 & 0x1)
> + /* accessing PMINTENSET_EL1 */
> + vcpu_sys_reg(vcpu, r->reg) |= (p->regval & mask);
> + else
> + /* accessing PMINTENCLR_EL1 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
> +
> + return true;
> +}
> +
Same bug again.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
@ 2016-01-07 11:13 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:13 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMINTENSET or PMINTENCLR register.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 3416881..24ce4fe 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -644,6 +644,25 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask = kvm_pmu_valid_counter_mask(vcpu);
> +
> + if (p->is_write) {
> + if (r->Op2 & 0x1)
> + /* accessing PMINTENSET_EL1 */
> + vcpu_sys_reg(vcpu, r->reg) |= (p->regval & mask);
> + else
> + /* accessing PMINTENCLR_EL1 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
> +
> + return true;
> +}
> +
Same bug again.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:14 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:14 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMOVSSET or PMOVSCLR register.
>
> When writing non-zero value to PMOVSSET, the counter and its interrupt
> is enabled, kick this vcpu to sync PMU interrupt.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 26 +++++++++++++++++++++++---
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 24ce4fe..d61f271dd 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -663,6 +663,25 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask = kvm_pmu_valid_counter_mask(vcpu);
> +
> + if (p->is_write) {
> + if (r->CRm & 0x2)
> + /* accessing PMOVSSET_EL0 */
> + kvm_pmu_overflow_set(vcpu, p->regval & mask);
> + else
> + /* accessing PMOVSCLR_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
> +
> + return true;
> +}
Same 32bit bug.
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -870,7 +889,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmcnten, NULL, PMCNTENSET_EL0 },
> /* PMOVSCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
> - trap_raz_wi },
> + access_pmovs, NULL, PMOVSSET_EL0 },
> /* PMSWINC_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
> trap_raz_wi },
> @@ -897,7 +916,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMOVSSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
> - trap_raz_wi },
> + access_pmovs, reset_unknown, PMOVSSET_EL0 },
>
> /* TPIDR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
> @@ -1211,7 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> @@ -1221,6 +1240,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
> { Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
> + { Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
>
> { Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
> { Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 9d2d0c0..244970b 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -39,6 +39,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -55,6 +56,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> }
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index bc64043..c23d57e 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -130,6 +130,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
> }
> }
>
> +static inline u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
Please drop the inline attribute.
> +{
> + u64 reg;
> +
> + reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
> + reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
> + reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
> + reg &= kvm_pmu_valid_counter_mask(vcpu);
> +
> + return reg;
> +}
> +
> +/**
> + * kvm_pmu_overflow_set - set PMU overflow interrupt
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMOVSSET register
> + */
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
> +{
> + u64 reg;
> +
> + if (val == 0)
> + return;
> +
> + vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
> + reg = kvm_pmu_overflow_status(vcpu);
> + if (reg != 0)
> + kvm_vcpu_kick(vcpu);
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
@ 2016-01-07 11:14 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:14 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
> reset_unknown for its reset handler. Add a handler to emulate writing
> PMOVSSET or PMOVSCLR register.
>
> When writing non-zero value to PMOVSSET, the counter and its interrupt
> is enabled, kick this vcpu to sync PMU interrupt.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 26 +++++++++++++++++++++++---
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 24ce4fe..d61f271dd 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -663,6 +663,25 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask = kvm_pmu_valid_counter_mask(vcpu);
> +
> + if (p->is_write) {
> + if (r->CRm & 0x2)
> + /* accessing PMOVSSET_EL0 */
> + kvm_pmu_overflow_set(vcpu, p->regval & mask);
> + else
> + /* accessing PMOVSCLR_EL0 */
> + vcpu_sys_reg(vcpu, r->reg) &= ~(p->regval & mask);
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, r->reg) & mask;
> + }
> +
> + return true;
> +}
Same 32bit bug.
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -870,7 +889,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmcnten, NULL, PMCNTENSET_EL0 },
> /* PMOVSCLR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
> - trap_raz_wi },
> + access_pmovs, NULL, PMOVSSET_EL0 },
> /* PMSWINC_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
> trap_raz_wi },
> @@ -897,7 +916,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMOVSSET_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
> - trap_raz_wi },
> + access_pmovs, reset_unknown, PMOVSSET_EL0 },
>
> /* TPIDR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
> @@ -1211,7 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> - { Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> @@ -1221,6 +1240,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
> { Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
> + { Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
>
> { Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
> { Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 9d2d0c0..244970b 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -39,6 +39,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -55,6 +56,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> }
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index bc64043..c23d57e 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -130,6 +130,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
> }
> }
>
> +static inline u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
Please drop the inline attribute.
> +{
> + u64 reg;
> +
> + reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
> + reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
> + reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
> + reg &= kvm_pmu_valid_counter_mask(vcpu);
> +
> + return reg;
> +}
> +
> +/**
> + * kvm_pmu_overflow_set - set PMU overflow interrupt
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMOVSSET register
> + */
> +void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
> +{
> + u64 reg;
> +
> + if (val == 0)
> + return;
> +
> + vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
> + reg = kvm_pmu_overflow_status(vcpu);
> + if (reg != 0)
> + kvm_vcpu_kick(vcpu);
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
2016-01-07 10:14 ` Marc Zyngier
(?)
@ 2016-01-07 11:15 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:15 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 18:14, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > This register resets as unknown in 64bit mode while it resets as zero
>> > in 32bit mode. Here we choose to reset it as zero for consistency.
>> >
>> > PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
>> > accessed from EL0. Add some check helpers to handle the access from EL0.
>> >
>> > When these bits are zero, only reading PMUSERENR will trap to EL2 and
>> > writing PMUSERENR or reading/writing other PMU registers will trap to
>> > EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
>> > (HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
>> > physical PMUSERENR register on VM entry, so that it will trap PMU access
>> > from EL0 to EL2. Within the register access handler we check the real
>> > value of guest PMUSERENR register to decide whether this access is
>> > allowed. If not allowed, forward this trap to EL1.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/include/asm/pmu.h | 9 ++++
>> > arch/arm64/kvm/hyp/switch.c | 3 ++
>> > arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
>> > 3 files changed, 129 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
>> > index 2588f9c..1238ade 100644
>> > --- a/arch/arm64/include/asm/pmu.h
>> > +++ b/arch/arm64/include/asm/pmu.h
>> > @@ -67,4 +67,13 @@
>> > #define ARMV8_EXCLUDE_EL0 (1 << 30)
>> > #define ARMV8_INCLUDE_EL2 (1 << 27)
>> >
>> > +/*
>> > + * PMUSERENR: user enable reg
>> > + */
>> > +#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
>> > +#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
>> > +#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
>> > +#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
>> > +#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read at EL0 */
>> > +
>> > #endif /* __ASM_PMU_H */
>> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> > index ca8f5a5..a85375f 100644
>> > --- a/arch/arm64/kvm/hyp/switch.c
>> > +++ b/arch/arm64/kvm/hyp/switch.c
>> > @@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>> > /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>> > write_sysreg(1 << 15, hstr_el2);
>> > write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>> > + /* Make sure we trap PMU access from EL0 to EL2 */
>> > + write_sysreg(15, pmuserenr_el0);
> Please use the ARMV8_USERENR_* constants here instead of a magic number
> (since you went through the hassle of defining them!).
>
Ok.
>> > write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
>> > }
>> >
>> > @@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
>> > write_sysreg(HCR_RW, hcr_el2);
>> > write_sysreg(0, hstr_el2);
>> > write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
>> > + write_sysreg(0, pmuserenr_el0);
>> > write_sysreg(0, cptr_el2);
>> > }
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 04281f1..ac0cbf8 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, r->reg) = val;
>> > }
>> >
>> > +static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
> Please drop all the inline attributes. The compiler knows its stuff well
> enough to do it automagically, and this is hardly a fast path...
>
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > const struct sys_reg_desc *r)
>> > {
>> > u64 val;
>> >
>> > + if (pmu_access_el0_disabled(vcpu)) {
>> > + kvm_forward_trap_to_el1(vcpu);
>> > + return true;
>> > + }
> So with the patch I posted earlier
> (http://www.spinics.net/lists/arm-kernel/msg472693.html), all the
> instances similar to that code can be rewritten as
>
> + if (pmu_access_el0_disabled(vcpu))
> + return false;
>
> You can then completely drop both patch 15 and my original patch to fix
> the PC stuff (which is far from being perfect, as noted by Peter).
Yeah, will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
@ 2016-01-07 11:15 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:15 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 18:14, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > This register resets as unknown in 64bit mode while it resets as zero
>> > in 32bit mode. Here we choose to reset it as zero for consistency.
>> >
>> > PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
>> > accessed from EL0. Add some check helpers to handle the access from EL0.
>> >
>> > When these bits are zero, only reading PMUSERENR will trap to EL2 and
>> > writing PMUSERENR or reading/writing other PMU registers will trap to
>> > EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
>> > (HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
>> > physical PMUSERENR register on VM entry, so that it will trap PMU access
>> > from EL0 to EL2. Within the register access handler we check the real
>> > value of guest PMUSERENR register to decide whether this access is
>> > allowed. If not allowed, forward this trap to EL1.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/include/asm/pmu.h | 9 ++++
>> > arch/arm64/kvm/hyp/switch.c | 3 ++
>> > arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
>> > 3 files changed, 129 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
>> > index 2588f9c..1238ade 100644
>> > --- a/arch/arm64/include/asm/pmu.h
>> > +++ b/arch/arm64/include/asm/pmu.h
>> > @@ -67,4 +67,13 @@
>> > #define ARMV8_EXCLUDE_EL0 (1 << 30)
>> > #define ARMV8_INCLUDE_EL2 (1 << 27)
>> >
>> > +/*
>> > + * PMUSERENR: user enable reg
>> > + */
>> > +#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
>> > +#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed at EL0 */
>> > +#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written at EL0 */
>> > +#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read at EL0 */
>> > +#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read at EL0 */
>> > +
>> > #endif /* __ASM_PMU_H */
>> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> > index ca8f5a5..a85375f 100644
>> > --- a/arch/arm64/kvm/hyp/switch.c
>> > +++ b/arch/arm64/kvm/hyp/switch.c
>> > @@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>> > /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>> > write_sysreg(1 << 15, hstr_el2);
>> > write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>> > + /* Make sure we trap PMU access from EL0 to EL2 */
>> > + write_sysreg(15, pmuserenr_el0);
> Please use the ARMV8_USERENR_* constants here instead of a magic number
> (since you went through the hassle of defining them!).
>
Ok.
>> > write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
>> > }
>> >
>> > @@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
>> > write_sysreg(HCR_RW, hcr_el2);
>> > write_sysreg(0, hstr_el2);
>> > write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
>> > + write_sysreg(0, pmuserenr_el0);
>> > write_sysreg(0, cptr_el2);
>> > }
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 04281f1..ac0cbf8 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, r->reg) = val;
>> > }
>> >
>> > +static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
> Please drop all the inline attributes. The compiler knows its stuff well
> enough to do it automagically, and this is hardly a fast path...
>
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > const struct sys_reg_desc *r)
>> > {
>> > u64 val;
>> >
>> > + if (pmu_access_el0_disabled(vcpu)) {
>> > + kvm_forward_trap_to_el1(vcpu);
>> > + return true;
>> > + }
> So with the patch I posted earlier
> (http://www.spinics.net/lists/arm-kernel/msg472693.html), all the
> instances similar to that code can be rewritten as
>
> + if (pmu_access_el0_disabled(vcpu))
> + return false;
>
> You can then completely drop both patch 15 and my original patch to fix
> the PC stuff (which is far from being perfect, as noted by Peter).
Yeah, will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register
@ 2016-01-07 11:15 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:15 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 18:14, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > This register resets as unknown in 64bit mode while it resets as zero
>> > in 32bit mode. Here we choose to reset it as zero for consistency.
>> >
>> > PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
>> > accessed from EL0. Add some check helpers to handle the access from EL0.
>> >
>> > When these bits are zero, only reading PMUSERENR will trap to EL2 and
>> > writing PMUSERENR or reading/writing other PMU registers will trap to
>> > EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
>> > (HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
>> > physical PMUSERENR register on VM entry, so that it will trap PMU access
>> > from EL0 to EL2. Within the register access handler we check the real
>> > value of guest PMUSERENR register to decide whether this access is
>> > allowed. If not allowed, forward this trap to EL1.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/include/asm/pmu.h | 9 ++++
>> > arch/arm64/kvm/hyp/switch.c | 3 ++
>> > arch/arm64/kvm/sys_regs.c | 122 +++++++++++++++++++++++++++++++++++++++++--
>> > 3 files changed, 129 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
>> > index 2588f9c..1238ade 100644
>> > --- a/arch/arm64/include/asm/pmu.h
>> > +++ b/arch/arm64/include/asm/pmu.h
>> > @@ -67,4 +67,13 @@
>> > #define ARMV8_EXCLUDE_EL0 (1 << 30)
>> > #define ARMV8_INCLUDE_EL2 (1 << 27)
>> >
>> > +/*
>> > + * PMUSERENR: user enable reg
>> > + */
>> > +#define ARMV8_USERENR_MASK 0xf /* Mask for writable bits */
>> > +#define ARMV8_USERENR_EN (1 << 0) /* PMU regs can be accessed@EL0 */
>> > +#define ARMV8_USERENR_SW (1 << 1) /* PMSWINC can be written@EL0 */
>> > +#define ARMV8_USERENR_CR (1 << 2) /* Cycle counter can be read@EL0 */
>> > +#define ARMV8_USERENR_ER (1 << 3) /* Event counter can be read@EL0 */
>> > +
>> > #endif /* __ASM_PMU_H */
>> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> > index ca8f5a5..a85375f 100644
>> > --- a/arch/arm64/kvm/hyp/switch.c
>> > +++ b/arch/arm64/kvm/hyp/switch.c
>> > @@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>> > /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>> > write_sysreg(1 << 15, hstr_el2);
>> > write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>> > + /* Make sure we trap PMU access from EL0 to EL2 */
>> > + write_sysreg(15, pmuserenr_el0);
> Please use the ARMV8_USERENR_* constants here instead of a magic number
> (since you went through the hassle of defining them!).
>
Ok.
>> > write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
>> > }
>> >
>> > @@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
>> > write_sysreg(HCR_RW, hcr_el2);
>> > write_sysreg(0, hstr_el2);
>> > write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
>> > + write_sysreg(0, pmuserenr_el0);
>> > write_sysreg(0, cptr_el2);
>> > }
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 04281f1..ac0cbf8 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -453,11 +453,47 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, r->reg) = val;
>> > }
>> >
>> > +static inline bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
> Please drop all the inline attributes. The compiler knows its stuff well
> enough to do it automagically, and this is hardly a fast path...
>
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > +static inline bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
>> > +{
>> > + u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
>> > +
>> > + return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
>> > + || vcpu_mode_priv(vcpu));
>> > +}
>> > +
>> > static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > const struct sys_reg_desc *r)
>> > {
>> > u64 val;
>> >
>> > + if (pmu_access_el0_disabled(vcpu)) {
>> > + kvm_forward_trap_to_el1(vcpu);
>> > + return true;
>> > + }
> So with the patch I posted earlier
> (http://www.spinics.net/lists/arm-kernel/msg472693.html), all the
> instances similar to that code can be rewritten as
>
> + if (pmu_access_el0_disabled(vcpu))
> + return false;
>
> You can then completely drop both patch 15 and my original patch to fix
> the PC stuff (which is far from being perfect, as noted by Peter).
Yeah, will fix this.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
2016-01-07 10:43 ` Marc Zyngier
(?)
@ 2016-01-07 11:16 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:16 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 18:43, Marc Zyngier wrote:
> On 22/12/15 08:07, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add reset handler which gets host value of PMCR_EL0 and make writable
>> > bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
>> > handler for PMCR.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
>> > 1 file changed, 37 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index e8bf374..c60047e 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -34,6 +34,7 @@
>> > #include <asm/kvm_emulate.h>
>> > #include <asm/kvm_host.h>
>> > #include <asm/kvm_mmu.h>
>> > +#include <asm/pmu.h>
>> >
>> > #include <trace/events/kvm.h>
>> >
>> > @@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
>> > }
>> >
>> > +static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
>> > + /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
>> > + * except PMCR.E resetting to zero.
>> > + */
>> > + val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
>> > + & (~ARMV8_PMCR_E);
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > +}
>> > +
>> > +static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 val;
>> > +
>> > + if (p->is_write) {
>> > + /* Only update writeable bits of PMCR */
>> > + val = vcpu_sys_reg(vcpu, r->reg);
>> > + val &= ~ARMV8_PMCR_MASK;
>> > + val |= p->regval & ARMV8_PMCR_MASK;
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > + } else {
>> > + /* PMCR.P & PMCR.C are RAZ */
>> > + val = vcpu_sys_reg(vcpu, r->reg)
>> > + & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
>> > + p->regval = val;
>> > + }
> How can that work for 32bit, where r->reg is not populated from the trap
> table? You *know* that you are accessing PMCR, so just use PMCR_EL0 as
> an index into vcpu_sys_reg() in all cases. You can then drop PMCR_EL0
> from the 64bit trap table entry.
>
Oh, sorry for this bug. Will fix this and those in other places.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
@ 2016-01-07 11:16 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:16 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 18:43, Marc Zyngier wrote:
> On 22/12/15 08:07, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add reset handler which gets host value of PMCR_EL0 and make writable
>> > bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
>> > handler for PMCR.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
>> > 1 file changed, 37 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index e8bf374..c60047e 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -34,6 +34,7 @@
>> > #include <asm/kvm_emulate.h>
>> > #include <asm/kvm_host.h>
>> > #include <asm/kvm_mmu.h>
>> > +#include <asm/pmu.h>
>> >
>> > #include <trace/events/kvm.h>
>> >
>> > @@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
>> > }
>> >
>> > +static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
>> > + /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
>> > + * except PMCR.E resetting to zero.
>> > + */
>> > + val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
>> > + & (~ARMV8_PMCR_E);
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > +}
>> > +
>> > +static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 val;
>> > +
>> > + if (p->is_write) {
>> > + /* Only update writeable bits of PMCR */
>> > + val = vcpu_sys_reg(vcpu, r->reg);
>> > + val &= ~ARMV8_PMCR_MASK;
>> > + val |= p->regval & ARMV8_PMCR_MASK;
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > + } else {
>> > + /* PMCR.P & PMCR.C are RAZ */
>> > + val = vcpu_sys_reg(vcpu, r->reg)
>> > + & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
>> > + p->regval = val;
>> > + }
> How can that work for 32bit, where r->reg is not populated from the trap
> table? You *know* that you are accessing PMCR, so just use PMCR_EL0 as
> an index into vcpu_sys_reg() in all cases. You can then drop PMCR_EL0
> from the 64bit trap table entry.
>
Oh, sorry for this bug. Will fix this and those in other places.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register
@ 2016-01-07 11:16 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 11:16 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 18:43, Marc Zyngier wrote:
> On 22/12/15 08:07, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add reset handler which gets host value of PMCR_EL0 and make writable
>> > bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
>> > handler for PMCR.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 39 +++++++++++++++++++++++++++++++++++++--
>> > 1 file changed, 37 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index e8bf374..c60047e 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -34,6 +34,7 @@
>> > #include <asm/kvm_emulate.h>
>> > #include <asm/kvm_host.h>
>> > #include <asm/kvm_mmu.h>
>> > +#include <asm/pmu.h>
>> >
>> > #include <trace/events/kvm.h>
>> >
>> > @@ -439,6 +440,40 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
>> > }
>> >
>> > +static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
>> > + /* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
>> > + * except PMCR.E resetting to zero.
>> > + */
>> > + val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
>> > + & (~ARMV8_PMCR_E);
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > +}
>> > +
>> > +static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 val;
>> > +
>> > + if (p->is_write) {
>> > + /* Only update writeable bits of PMCR */
>> > + val = vcpu_sys_reg(vcpu, r->reg);
>> > + val &= ~ARMV8_PMCR_MASK;
>> > + val |= p->regval & ARMV8_PMCR_MASK;
>> > + vcpu_sys_reg(vcpu, r->reg) = val;
>> > + } else {
>> > + /* PMCR.P & PMCR.C are RAZ */
>> > + val = vcpu_sys_reg(vcpu, r->reg)
>> > + & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
>> > + p->regval = val;
>> > + }
> How can that work for 32bit, where r->reg is not populated from the trap
> table? You *know* that you are accessing PMCR, so just use PMCR_EL0 as
> an index into vcpu_sys_reg() in all cases. You can then drop PMCR_EL0
> from the 64bit trap table entry.
>
Oh, sorry for this bug. Will fix this and those in other places.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:29 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:29 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add access handler which emulates writing and reading PMSWINC
> register and add support for creating software increment event.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 18 +++++++++++++++++-
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index d61f271dd..92021dc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -682,6 +682,21 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask;
> +
> + if (p->is_write) {
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + kvm_pmu_software_increment(vcpu, p->regval & mask);
> + } else {
> + kvm_inject_undefined(vcpu);
"return false;" instead.
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -892,7 +907,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmovs, NULL, PMOVSSET_EL0 },
> /* PMSWINC_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
> - trap_raz_wi },
> + access_pmswinc, reset_unknown, PMSWINC_EL0 },
> /* PMSELR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
> access_pmselr, reset_unknown, PMSELR_EL0 },
> @@ -1231,6 +1246,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 244970b..67d168c 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index c23d57e..409f3c4 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -160,6 +160,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
> kvm_vcpu_kick(vcpu);
> }
>
> +/**
> + * kvm_pmu_software_increment - do software increment
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMSWINC register
> + */
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + u64 type, enable, reg;
> +
> + if (val == 0)
> + return;
> +
> + for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
> + if (!(val & BIT(i)))
> + continue;
> + type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
> + & ARMV8_EVTYPE_EVENT;
> + enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
> + if ((type == 0) && (enable & BIT(i))) {
nit: Should we have a ARMV8_EVTYPE_EVENT_SW_INCR instead of just
checking for zero?
> + reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
> + reg = lower_32_bits(reg);
> + vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
> + if (!reg)
> + kvm_pmu_overflow_set(vcpu, BIT(i));
> + }
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
> @@ -189,6 +218,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> kvm_pmu_stop_counter(vcpu, pmc);
> eventsel = data & ARMV8_EVTYPE_EVENT;
>
> + /* For software increment event it does't need to create perf event */
nit: ... "Software events do not need to be backed by a perf event"
> + if (eventsel == 0)
> + return;
> +
> memset(&attr, 0, sizeof(struct perf_event_attr));
> attr.type = PERF_TYPE_RAW;
> attr.size = sizeof(attr);
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register
@ 2016-01-07 11:29 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:29 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add access handler which emulates writing and reading PMSWINC
> register and add support for creating software increment event.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 18 +++++++++++++++++-
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index d61f271dd..92021dc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -682,6 +682,21 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 mask;
> +
> + if (p->is_write) {
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + kvm_pmu_software_increment(vcpu, p->regval & mask);
> + } else {
> + kvm_inject_undefined(vcpu);
"return false;" instead.
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -892,7 +907,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> access_pmovs, NULL, PMOVSSET_EL0 },
> /* PMSWINC_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
> - trap_raz_wi },
> + access_pmswinc, reset_unknown, PMSWINC_EL0 },
> /* PMSELR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
> access_pmselr, reset_unknown, PMSELR_EL0 },
> @@ -1231,6 +1246,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
> { Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
> + { Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
> { Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 244970b..67d168c 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -40,6 +40,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -57,6 +58,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
> void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index c23d57e..409f3c4 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -160,6 +160,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
> kvm_vcpu_kick(vcpu);
> }
>
> +/**
> + * kvm_pmu_software_increment - do software increment
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMSWINC register
> + */
> +void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
> +{
> + int i;
> + u64 type, enable, reg;
> +
> + if (val == 0)
> + return;
> +
> + for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
> + if (!(val & BIT(i)))
> + continue;
> + type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
> + & ARMV8_EVTYPE_EVENT;
> + enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
> + if ((type == 0) && (enable & BIT(i))) {
nit: Should we have a ARMV8_EVTYPE_EVENT_SW_INCR instead of just
checking for zero?
> + reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
> + reg = lower_32_bits(reg);
> + vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
> + if (!reg)
> + kvm_pmu_overflow_set(vcpu, BIT(i));
> + }
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
> @@ -189,6 +218,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> kvm_pmu_stop_counter(vcpu, pmc);
> eventsel = data & ARMV8_EVTYPE_EVENT;
>
> + /* For software increment event it does't need to create perf event */
nit: ... "Software events do not need to be backed by a perf event"
> + if (eventsel == 0)
> + return;
> +
> memset(&attr, 0, sizeof(struct perf_event_attr));
> attr.type = PERF_TYPE_RAW;
> attr.size = sizeof(attr);
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 11:59 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:59 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
> enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
> disabled. When writing 1 to PMCR.P, reset all event counters, not
> including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
> zero.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 1 +
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 92021dc..04281f1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -464,6 +464,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> val &= ~ARMV8_PMCR_MASK;
> val |= p->regval & ARMV8_PMCR_MASK;
> vcpu_sys_reg(vcpu, r->reg) = val;
> + kvm_pmu_handle_pmcr(vcpu, val);
> } else {
> /* PMCR.P & PMCR.C are RAZ */
> val = vcpu_sys_reg(vcpu, r->reg)
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 67d168c..7ec7706 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -41,6 +41,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -59,6 +60,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 409f3c4..fda32cb 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -189,6 +189,48 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
> }
> }
>
> +/**
> + * kvm_pmu_handle_pmcr - handle PMCR register
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCR register
> + */
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
> +{
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> + u64 mask;
> + int i;
> +
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + if (val & ARMV8_PMCR_E) {
> + kvm_pmu_enable_counter(vcpu,
> + vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
> + } else {
> + kvm_pmu_disable_counter(vcpu, mask);
> + }
> +
> + if (val & ARMV8_PMCR_C) {
> + pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
> + if (pmc->perf_event)
> + local64_set(&pmc->perf_event->count, 0);
> + vcpu_sys_reg(vcpu, PMCCNTR_EL0) = 0;
> + }
> +
> + if (val & ARMV8_PMCR_P) {
> + for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event)
> + local64_set(&pmc->perf_event->count, 0);
As much as I'm scared by the idea of directly messing with the perf
internals, I can't find another way of doing this, and perf itself
doesn't seen to do any locking when resetting the counter.
> + vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = 0;
> + }
> + }
> +
> + if (val & ARMV8_PMCR_LC) {
> + pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
> + pmc->bitmask = 0xffffffffffffffffUL;
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits
@ 2016-01-07 11:59 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 11:59 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
> enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
> disabled. When writing 1 to PMCR.P, reset all event counters, not
> including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
> zero.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 1 +
> include/kvm/arm_pmu.h | 2 ++
> virt/kvm/arm/pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 92021dc..04281f1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -464,6 +464,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> val &= ~ARMV8_PMCR_MASK;
> val |= p->regval & ARMV8_PMCR_MASK;
> vcpu_sys_reg(vcpu, r->reg) = val;
> + kvm_pmu_handle_pmcr(vcpu, val);
> } else {
> /* PMCR.P & PMCR.C are RAZ */
> val = vcpu_sys_reg(vcpu, r->reg)
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 67d168c..7ec7706 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -41,6 +41,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> #else
> @@ -59,6 +60,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx) {}
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 409f3c4..fda32cb 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -189,6 +189,48 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
> }
> }
>
> +/**
> + * kvm_pmu_handle_pmcr - handle PMCR register
> + * @vcpu: The vcpu pointer
> + * @val: the value guest writes to PMCR register
> + */
> +void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
> +{
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc;
> + u64 mask;
> + int i;
> +
> + mask = kvm_pmu_valid_counter_mask(vcpu);
> + if (val & ARMV8_PMCR_E) {
> + kvm_pmu_enable_counter(vcpu,
> + vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
> + } else {
> + kvm_pmu_disable_counter(vcpu, mask);
> + }
> +
> + if (val & ARMV8_PMCR_C) {
> + pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
> + if (pmc->perf_event)
> + local64_set(&pmc->perf_event->count, 0);
> + vcpu_sys_reg(vcpu, PMCCNTR_EL0) = 0;
> + }
> +
> + if (val & ARMV8_PMCR_P) {
> + for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
> + pmc = &pmu->pmc[i];
> + if (pmc->perf_event)
> + local64_set(&pmc->perf_event->count, 0);
As much as I'm scared by the idea of directly messing with the perf
internals, I can't find another way of doing this, and perf itself
doesn't seen to do any locking when resetting the counter.
> + vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = 0;
> + }
> + }
> +
> + if (val & ARMV8_PMCR_LC) {
> + pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
> + pmc->bitmask = 0xffffffffffffffffUL;
> + }
> +}
> +
> static inline bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu,
> u64 select_idx)
> {
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2015-12-22 8:08 ` Shannon Zhao
(?)
@ 2016-01-07 12:09 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:09 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 2015/12/22 16:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
Hi Marc,
Here should we return false to inject an UND since there is no
PMEVTYPER(idx)_EL0? The ARMv8 spec says it should.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 12:09 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:09 UTC (permalink / raw)
To: kvmarm, marc.zyngier, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 2015/12/22 16:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
Hi Marc,
Here should we return false to inject an UND since there is no
PMEVTYPER(idx)_EL0? The ARMv8 spec says it should.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 12:09 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:09 UTC (permalink / raw)
To: linux-arm-kernel
On 2015/12/22 16:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
Hi Marc,
Here should we return false to inject an UND since there is no
PMEVTYPER(idx)_EL0? The ARMv8 spec says it should.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2016-01-07 11:03 ` Marc Zyngier
(?)
@ 2016-01-07 12:36 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:36 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
It turns out that I refactor this function like below:
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct
sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg = 0;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ reg = PMEVTYPER0_EL0 + idx;
+ } else {
+ if (r->CRm == 15 && r->Op2 == 7) {
+ idx = ARMV8_CYCLE_IDX;
+ reg = PMCCFILTR_EL0;
+ } else {
+ /* PMEVTYPERn_EL0 */
+ idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg = PMEVTYPER0_EL0 + idx;
+ }
+ }
+
+ BUG_ON(reg == 0);
+
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return false;
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
How about this?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 12:36 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:36 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
It turns out that I refactor this function like below:
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct
sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg = 0;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ reg = PMEVTYPER0_EL0 + idx;
+ } else {
+ if (r->CRm == 15 && r->Op2 == 7) {
+ idx = ARMV8_CYCLE_IDX;
+ reg = PMCCFILTR_EL0;
+ } else {
+ /* PMEVTYPERn_EL0 */
+ idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg = PMEVTYPER0_EL0 + idx;
+ }
+ }
+
+ BUG_ON(reg == 0);
+
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return false;
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
How about this?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 12:36 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 12:36 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 19:03, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> > which is mapped to PMEVTYPERn or PMCCFILTR.
>> >
>> > The access handler translates all aarch32 register offsets to aarch64
>> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> > of big endian.
>> >
>> > When writing to these registers, create a perf_event for the selected
>> > event type.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 154 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 2552db1..ed2939b 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > return true;
>> > }
>> >
>> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> > +{
>> > + u64 pmcr, val;
>> > +
>> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> > + const struct sys_reg_desc *r)
>> > +{
>> > + u64 idx, reg;
>> > +
>> > + if (r->CRn == 9) {
>> > + /* PMXEVTYPER_EL0 */
>> > + reg = 0;
> Is there any particular reason why you're not setting reg to PMSELR_EL0,
> since this is what you're using?
>
>> > + } else {
>> > + if (!p->is_aarch32) {
>> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> > + reg = r->reg;
>> > + } else {
>> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> > + reg = PMCCFILTR_EL0;
>> > + } else {
>> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> > + reg += PMEVTYPER0_EL0;
>> > + }
>> > + }
>> > + }
>> > +
>> > + switch (reg) {
>> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> > + idx = reg - PMEVTYPER0_EL0;
>> > + if (!pmu_counter_idx_valid(vcpu, idx))
>> > + return true;
>> > + break;
>> > + case PMCCFILTR_EL0:
>> > + idx = ARMV8_CYCLE_IDX;
>> > + break;
>> > + default:
> This would allow this case to be more precise, and we could have the
> default case as a bug handler.
>
It turns out that I refactor this function like below:
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct
sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u64 idx, reg = 0;
+
+ if (r->CRn == 9) {
+ /* PMXEVTYPER_EL0 */
+ idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+ reg = PMEVTYPER0_EL0 + idx;
+ } else {
+ if (r->CRm == 15 && r->Op2 == 7) {
+ idx = ARMV8_CYCLE_IDX;
+ reg = PMCCFILTR_EL0;
+ } else {
+ /* PMEVTYPERn_EL0 */
+ idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+ reg = PMEVTYPER0_EL0 + idx;
+ }
+ }
+
+ BUG_ON(reg == 0);
+
+ if (!pmu_counter_idx_valid(vcpu, idx))
+ return false;
+
+ if (p->is_write) {
+ kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+ vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+ } else {
+ p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+ }
+
+ return true;
+}
How about this?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2016-01-07 12:09 ` Shannon Zhao
@ 2016-01-07 13:01 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:01 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 07/01/16 12:09, Shannon Zhao wrote:
>
>
> On 2015/12/22 16:08, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> which is mapped to PMEVTYPERn or PMCCFILTR.
>>
>> The access handler translates all aarch32 register offsets to aarch64
>> ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> of big endian.
>>
>> When writing to these registers, create a perf_event for the selected
>> event type.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 154 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 2552db1..ed2939b 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> return true;
>> }
>>
>> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> +{
>> + u64 pmcr, val;
>> +
>> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + u64 idx, reg;
>> +
>> + if (r->CRn == 9) {
>> + /* PMXEVTYPER_EL0 */
>> + reg = 0;
>> + } else {
>> + if (!p->is_aarch32) {
>> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> + reg = r->reg;
>> + } else {
>> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> + reg = PMCCFILTR_EL0;
>> + } else {
>> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> + reg += PMEVTYPER0_EL0;
>> + }
>> + }
>> + }
>> +
>> + switch (reg) {
>> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> + idx = reg - PMEVTYPER0_EL0;
>> + if (!pmu_counter_idx_valid(vcpu, idx))
>> + return true;
> Hi Marc,
>
> Here should we return false to inject an UND since there is no
> PMEVTYPER(idx)_EL0? The ARMv8 spec says it should.
The spec says that the following behaviours are valid:
- Accesses to the register are UNDEFINED .
- Accesses to the register behave as RAZ/WI.
- Accesses to the register execute as a NOP .
Same for the counters. So you can either return true (act as a NOP), or
return false (UNDEF), and even zero r->regval on read and return true
(RAZ/WI).
This is entirely up to you. My personal preference is indeed to UNDEF,
but your current implementation is valid.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 13:01 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:01 UTC (permalink / raw)
To: linux-arm-kernel
On 07/01/16 12:09, Shannon Zhao wrote:
>
>
> On 2015/12/22 16:08, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
>> which is mapped to PMEVTYPERn or PMCCFILTR.
>>
>> The access handler translates all aarch32 register offsets to aarch64
>> ones and uses vcpu_sys_reg() to access their values to avoid taking care
>> of big endian.
>>
>> When writing to these registers, create a perf_event for the selected
>> event type.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 154 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 2552db1..ed2939b 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> return true;
>> }
>>
>> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>> +{
>> + u64 pmcr, val;
>> +
>> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
>> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
>> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + u64 idx, reg;
>> +
>> + if (r->CRn == 9) {
>> + /* PMXEVTYPER_EL0 */
>> + reg = 0;
>> + } else {
>> + if (!p->is_aarch32) {
>> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
>> + reg = r->reg;
>> + } else {
>> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
>> + reg = PMCCFILTR_EL0;
>> + } else {
>> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
>> + reg += PMEVTYPER0_EL0;
>> + }
>> + }
>> + }
>> +
>> + switch (reg) {
>> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
>> + idx = reg - PMEVTYPER0_EL0;
>> + if (!pmu_counter_idx_valid(vcpu, idx))
>> + return true;
> Hi Marc,
>
> Here should we return false to inject an UND since there is no
> PMEVTYPER(idx)_EL0? The ARMv8 spec says it should.
The spec says that the following behaviours are valid:
- Accesses to the register are UNDEFINED .
- Accesses to the register behave as RAZ/WI.
- Accesses to the register execute as a NOP .
Same for the counters. So you can either return true (act as a NOP), or
return false (UNDEF), and even zero r->regval on read and return true
(RAZ/WI).
This is entirely up to you. My personal preference is indeed to UNDEF,
but your current implementation is valid.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2016-01-07 12:36 ` Shannon Zhao
@ 2016-01-07 13:15 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:15 UTC (permalink / raw)
To: Shannon Zhao; +Cc: kvm, shannon.zhao, will.deacon, kvmarm, linux-arm-kernel
On Thu, 7 Jan 2016 20:36:45 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 19:03, Marc Zyngier wrote:
> > On 22/12/15 08:08, Shannon Zhao wrote:
> >> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >> >
> >> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> >> > which is mapped to PMEVTYPERn or PMCCFILTR.
> >> >
> >> > The access handler translates all aarch32 register offsets to aarch64
> >> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
> >> > of big endian.
> >> >
> >> > When writing to these registers, create a perf_event for the selected
> >> > event type.
> >> >
> >> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >> > ---
> >> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> >> > 1 file changed, 154 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >> > index 2552db1..ed2939b 100644
> >> > --- a/arch/arm64/kvm/sys_regs.c
> >> > +++ b/arch/arm64/kvm/sys_regs.c
> >> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >> > return true;
> >> > }
> >> >
> >> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> >> > +{
> >> > + u64 pmcr, val;
> >> > +
> >> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> >> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> >> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> >> > + return false;
> >> > +
> >> > + return true;
> >> > +}
> >> > +
> >> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >> > + const struct sys_reg_desc *r)
> >> > +{
> >> > + u64 idx, reg;
> >> > +
> >> > + if (r->CRn == 9) {
> >> > + /* PMXEVTYPER_EL0 */
> >> > + reg = 0;
> > Is there any particular reason why you're not setting reg to PMSELR_EL0,
> > since this is what you're using?
> >
> >> > + } else {
> >> > + if (!p->is_aarch32) {
> >> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> >> > + reg = r->reg;
> >> > + } else {
> >> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> >> > + reg = PMCCFILTR_EL0;
> >> > + } else {
> >> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> >> > + reg += PMEVTYPER0_EL0;
> >> > + }
> >> > + }
> >> > + }
> >> > +
> >> > + switch (reg) {
> >> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> >> > + idx = reg - PMEVTYPER0_EL0;
> >> > + if (!pmu_counter_idx_valid(vcpu, idx))
> >> > + return true;
> >> > + break;
> >> > + case PMCCFILTR_EL0:
> >> > + idx = ARMV8_CYCLE_IDX;
> >> > + break;
> >> > + default:
> > This would allow this case to be more precise, and we could have the
> > default case as a bug handler.
> >
>
> It turns out that I refactor this function like below:
>
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct
> sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg = 0;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + reg = PMEVTYPER0_EL0 + idx;
> + } else {
> + if (r->CRm == 15 && r->Op2 == 7) {
> + idx = ARMV8_CYCLE_IDX;
> + reg = PMCCFILTR_EL0;
> + } else {
> + /* PMEVTYPERn_EL0 */
> + idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg = PMEVTYPER0_EL0 + idx;
> + }
> + }
> +
> + BUG_ON(reg == 0);
> +
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return false;
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
>
> How about this?
Yup, looks good to me.
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 13:15 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 7 Jan 2016 20:36:45 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 19:03, Marc Zyngier wrote:
> > On 22/12/15 08:08, Shannon Zhao wrote:
> >> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >> >
> >> > These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> >> > which is mapped to PMEVTYPERn or PMCCFILTR.
> >> >
> >> > The access handler translates all aarch32 register offsets to aarch64
> >> > ones and uses vcpu_sys_reg() to access their values to avoid taking care
> >> > of big endian.
> >> >
> >> > When writing to these registers, create a perf_event for the selected
> >> > event type.
> >> >
> >> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >> > ---
> >> > arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> >> > 1 file changed, 154 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >> > index 2552db1..ed2939b 100644
> >> > --- a/arch/arm64/kvm/sys_regs.c
> >> > +++ b/arch/arm64/kvm/sys_regs.c
> >> > @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >> > return true;
> >> > }
> >> >
> >> > +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> >> > +{
> >> > + u64 pmcr, val;
> >> > +
> >> > + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> >> > + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> >> > + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> >> > + return false;
> >> > +
> >> > + return true;
> >> > +}
> >> > +
> >> > +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >> > + const struct sys_reg_desc *r)
> >> > +{
> >> > + u64 idx, reg;
> >> > +
> >> > + if (r->CRn == 9) {
> >> > + /* PMXEVTYPER_EL0 */
> >> > + reg = 0;
> > Is there any particular reason why you're not setting reg to PMSELR_EL0,
> > since this is what you're using?
> >
> >> > + } else {
> >> > + if (!p->is_aarch32) {
> >> > + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> >> > + reg = r->reg;
> >> > + } else {
> >> > + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> >> > + reg = PMCCFILTR_EL0;
> >> > + } else {
> >> > + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> >> > + reg += PMEVTYPER0_EL0;
> >> > + }
> >> > + }
> >> > + }
> >> > +
> >> > + switch (reg) {
> >> > + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> >> > + idx = reg - PMEVTYPER0_EL0;
> >> > + if (!pmu_counter_idx_valid(vcpu, idx))
> >> > + return true;
> >> > + break;
> >> > + case PMCCFILTR_EL0:
> >> > + idx = ARMV8_CYCLE_IDX;
> >> > + break;
> >> > + default:
> > This would allow this case to be more precise, and we could have the
> > default case as a bug handler.
> >
>
> It turns out that I refactor this function like below:
>
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct
> sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg = 0;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + reg = PMEVTYPER0_EL0 + idx;
> + } else {
> + if (r->CRm == 15 && r->Op2 == 7) {
> + idx = ARMV8_CYCLE_IDX;
> + reg = PMCCFILTR_EL0;
> + } else {
> + /* PMEVTYPERn_EL0 */
> + idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg = PMEVTYPER0_EL0 + idx;
> + }
> + }
> +
> + BUG_ON(reg == 0);
> +
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return false;
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
>
> How about this?
Yup, looks good to me.
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
2015-12-22 8:08 ` Shannon Zhao
(?)
@ 2016-01-07 13:28 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:28 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, 22 Dec 2015 16:08:12 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
>
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
@ 2016-01-07 13:28 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:28 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, 22 Dec 2015 16:08:12 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
>
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing
@ 2016-01-07 13:28 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:28 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Dec 2015 16:08:12 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
>
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
2015-12-22 8:08 ` Shannon Zhao
(?)
@ 2016-01-07 13:39 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:39 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, 22 Dec 2015 16:08:13 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When resetting vcpu, it needs to reset the PMU state to initial status.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
@ 2016-01-07 13:39 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:39 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, 22 Dec 2015 16:08:13 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When resetting vcpu, it needs to reset the PMU state to initial status.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu
@ 2016-01-07 13:39 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Dec 2015 16:08:13 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When resetting vcpu, it needs to reset the PMU state to initial status.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 13:48 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:48 UTC (permalink / raw)
To: Shannon Zhao; +Cc: kvm, shannon.zhao, will.deacon, kvmarm, linux-arm-kernel
On Tue, 22 Dec 2015 16:08:02 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When we use tools like perf on host, perf passes the event type and the
> id of this event type category to kernel, then kernel will map them to
> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
> register. When getting the event number in KVM, directly use raw event
> type to create a perf_event for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 3 ++
> arch/arm64/kvm/Makefile | 1 +
> include/kvm/arm_pmu.h | 11 ++++
> virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 137 insertions(+)
> create mode 100644 virt/kvm/arm/pmu.c
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 4406184..2588f9c 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -21,6 +21,7 @@
>
> #define ARMV8_MAX_COUNTERS 32
> #define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
> +#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
>
> /*
> * Per-CPU PMCR: config reg
> @@ -31,6 +32,8 @@
> #define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
> #define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
> #define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
> +/* Determines which PMCCNTR_EL0 bit generates an overflow */
> +#define ARMV8_PMCR_LC (1 << 6)
> #define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
> #define ARMV8_PMCR_N_MASK 0x1f
> #define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index caee9ee..122cff4 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> +kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index ddcb5b2..14bedb0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -34,9 +34,20 @@ struct kvm_pmu {
> int irq_num;
> struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx);
> #else
> struct kvm_pmu {
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + return 0;
> +}
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx) {}
> #endif
>
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> new file mode 100644
> index 0000000..9d27999
> --- /dev/null
> +++ b/virt/kvm/arm/pmu.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/perf_event.h>
> +#include <asm/kvm_emulate.h>
> +#include <kvm/arm_pmu.h>
> +
> +/**
> + * kvm_pmu_get_counter_value - get PMU counter value
> + * @vcpu: The vcpu pointer
> + * @select_idx: The counter index
> + */
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + u64 counter, reg, enabled, running;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> +
> + reg = (select_idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
> + counter = vcpu_sys_reg(vcpu, reg);
> +
> + /* The real counter value is equal to the value of counter register plus
> + * the value perf event counts.
> + */
> + if (pmc->perf_event)
> + counter += perf_event_read_value(pmc->perf_event, &enabled,
> + &running);
> +
> + return counter & pmc->bitmask;
> +}
> +
> +/**
> + * kvm_pmu_stop_counter - stop PMU counter
> + * @pmc: The PMU counter pointer
> + *
> + * If this counter has been configured to monitor some event, release it here.
> + */
> +static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> +{
> + u64 counter, reg;
> +
> + if (pmc->perf_event) {
> + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
> + reg = (pmc->idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
> + vcpu_sys_reg(vcpu, reg) = counter;
> + perf_event_release_kernel(pmc->perf_event);
I'm having second thoughts about this one. Don't you need to first
disable the event? You seem to be doing it on the destroy path, and it
worries me that we're not doing the same thing on both paths.
Thoughts?
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2016-01-07 13:48 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:48 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Dec 2015 16:08:02 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When we use tools like perf on host, perf passes the event type and the
> id of this event type category to kernel, then kernel will map them to
> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
> register. When getting the event number in KVM, directly use raw event
> type to create a perf_event for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/pmu.h | 3 ++
> arch/arm64/kvm/Makefile | 1 +
> include/kvm/arm_pmu.h | 11 ++++
> virt/kvm/arm/pmu.c | 122 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 137 insertions(+)
> create mode 100644 virt/kvm/arm/pmu.c
>
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> index 4406184..2588f9c 100644
> --- a/arch/arm64/include/asm/pmu.h
> +++ b/arch/arm64/include/asm/pmu.h
> @@ -21,6 +21,7 @@
>
> #define ARMV8_MAX_COUNTERS 32
> #define ARMV8_COUNTER_MASK (ARMV8_MAX_COUNTERS - 1)
> +#define ARMV8_CYCLE_IDX (ARMV8_MAX_COUNTERS - 1)
>
> /*
> * Per-CPU PMCR: config reg
> @@ -31,6 +32,8 @@
> #define ARMV8_PMCR_D (1 << 3) /* CCNT counts every 64th cpu cycle */
> #define ARMV8_PMCR_X (1 << 4) /* Export to ETM */
> #define ARMV8_PMCR_DP (1 << 5) /* Disable CCNT if non-invasive debug*/
> +/* Determines which PMCCNTR_EL0 bit generates an overflow */
> +#define ARMV8_PMCR_LC (1 << 6)
> #define ARMV8_PMCR_N_SHIFT 11 /* Number of counters supported */
> #define ARMV8_PMCR_N_MASK 0x1f
> #define ARMV8_PMCR_MASK 0x3f /* Mask for writable bits */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index caee9ee..122cff4 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> +kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index ddcb5b2..14bedb0 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -34,9 +34,20 @@ struct kvm_pmu {
> int irq_num;
> struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx);
> #else
> struct kvm_pmu {
> };
> +
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + return 0;
> +}
> +void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> + u64 select_idx) {}
> #endif
>
> #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> new file mode 100644
> index 0000000..9d27999
> --- /dev/null
> +++ b/virt/kvm/arm/pmu.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/kvm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/perf_event.h>
> +#include <asm/kvm_emulate.h>
> +#include <kvm/arm_pmu.h>
> +
> +/**
> + * kvm_pmu_get_counter_value - get PMU counter value
> + * @vcpu: The vcpu pointer
> + * @select_idx: The counter index
> + */
> +u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
> +{
> + u64 counter, reg, enabled, running;
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> + struct kvm_pmc *pmc = &pmu->pmc[select_idx];
> +
> + reg = (select_idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
> + counter = vcpu_sys_reg(vcpu, reg);
> +
> + /* The real counter value is equal to the value of counter register plus
> + * the value perf event counts.
> + */
> + if (pmc->perf_event)
> + counter += perf_event_read_value(pmc->perf_event, &enabled,
> + &running);
> +
> + return counter & pmc->bitmask;
> +}
> +
> +/**
> + * kvm_pmu_stop_counter - stop PMU counter
> + * @pmc: The PMU counter pointer
> + *
> + * If this counter has been configured to monitor some event, release it here.
> + */
> +static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
> +{
> + u64 counter, reg;
> +
> + if (pmc->perf_event) {
> + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
> + reg = (pmc->idx == ARMV8_CYCLE_IDX)
> + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
> + vcpu_sys_reg(vcpu, reg) = counter;
> + perf_event_release_kernel(pmc->perf_event);
I'm having second thoughts about this one. Don't you need to first
disable the event? You seem to be doing it on the destroy path, and it
worries me that we're not doing the same thing on both paths.
Thoughts?
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 13:51 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:51 UTC (permalink / raw)
To: Shannon Zhao; +Cc: kvm, shannon.zhao, will.deacon, kvmarm, linux-arm-kernel
On Tue, 22 Dec 2015 16:08:14 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When KVM frees VCPU, it needs to free the perf_event of PMU.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu
@ 2016-01-07 13:51 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Dec 2015 16:08:14 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> When KVM frees VCPU, it needs to free the perf_event of PMU.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 13:56 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:56 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
I don't see anything enforcing these restrictions in the code (you can
program different PPIs on each vcpu, or the same SPI everywhere, and
nothing will generate an error).
Is that something we want to enforce? Or we're happy just to leave it as
an unsupported corner case?
> +
> + Errors:
> + -ENXIO: Unsupported attribute group
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2d4ca4b..cbb9022 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> +/* Device Control API: ARM PMU */
> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
> +
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c923350..608dea6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> extern struct kvm_device_ops kvm_xics_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 03f3618..4ba6fdd 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> KVM_DEV_TYPE_ARM_VGIC_V3,
> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> + KVM_DEV_TYPE_ARM_PMU_V3,
> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 3ec3cdd..5518308 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -19,6 +19,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <linux/perf_event.h>
> +#include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> #include <kvm/arm_vgic.h>
> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>
> pmc->perf_event = event;
> }
> +
> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.pmu.irq_num != -1;
> +}
> +
> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> + int *irq, bool is_set)
> +{
> + int cpuid;
> + struct kvm_vcpu *vcpu;
> + struct kvm_pmu *pmu;
> +
> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> + return -EINVAL;
> +
> + vcpu = kvm_get_vcpu(kvm, cpuid);
> + if (!vcpu)
> + return -EINVAL;
> +
> + pmu = &vcpu->arch.pmu;
> + if (!is_set) {
> + if (!kvm_arm_pmu_initialized(vcpu))
> + return -ENODEV;
> +
> + *irq = pmu->irq_num;
> + } else {
> + if (kvm_arm_pmu_initialized(vcpu))
> + return -EBUSY;
> +
> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> + pmu->irq_num = *irq;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> +{
> + int i;
> + struct kvm_vcpu *vcpu;
> + struct kvm *kvm = dev->kvm;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +
> + memset(pmu, 0, sizeof(*pmu));
> + kvm_pmu_vcpu_reset(vcpu);
> + pmu->irq_num = -1;
> + }
> +
> + return 0;
> +}
> +
> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg;
> +
> + if (get_user(reg, uaddr))
> + return -EFAULT;
> +
> + /*
> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> + * VM the interrupt type must be same for each vcpu. As a PPI,
> + * the interrupt number is same for all vcpus, while as a SPI it
> + * must be different for each vcpu.
> + */
> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> + return -EINVAL;
> +
> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + int ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg = -1;
> +
> +
> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> + if (ret)
> + return ret;
> + return put_user(reg, uaddr);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> + return 0;
> + }
> +
> + return -ENXIO;
> +}
> +
> +struct kvm_device_ops kvm_arm_pmu_ops = {
> + .name = "kvm-arm-pmu",
> + .create = kvm_arm_pmu_create,
> + .destroy = kvm_arm_pmu_destroy,
> + .set_attr = kvm_arm_pmu_set_attr,
> + .get_attr = kvm_arm_pmu_get_attr,
> + .has_attr = kvm_arm_pmu_has_attr,
> +};
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 484079e..81a42cc 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> #ifdef CONFIG_KVM_XICS
> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> #endif
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
> +#endif
> };
>
> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 13:56 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 13:56 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
I don't see anything enforcing these restrictions in the code (you can
program different PPIs on each vcpu, or the same SPI everywhere, and
nothing will generate an error).
Is that something we want to enforce? Or we're happy just to leave it as
an unsupported corner case?
> +
> + Errors:
> + -ENXIO: Unsupported attribute group
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2d4ca4b..cbb9022 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> +/* Device Control API: ARM PMU */
> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
> +
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c923350..608dea6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> extern struct kvm_device_ops kvm_xics_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 03f3618..4ba6fdd 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> KVM_DEV_TYPE_ARM_VGIC_V3,
> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> + KVM_DEV_TYPE_ARM_PMU_V3,
> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 3ec3cdd..5518308 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -19,6 +19,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <linux/perf_event.h>
> +#include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> #include <kvm/arm_vgic.h>
> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>
> pmc->perf_event = event;
> }
> +
> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.pmu.irq_num != -1;
> +}
> +
> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> + int *irq, bool is_set)
> +{
> + int cpuid;
> + struct kvm_vcpu *vcpu;
> + struct kvm_pmu *pmu;
> +
> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> + return -EINVAL;
> +
> + vcpu = kvm_get_vcpu(kvm, cpuid);
> + if (!vcpu)
> + return -EINVAL;
> +
> + pmu = &vcpu->arch.pmu;
> + if (!is_set) {
> + if (!kvm_arm_pmu_initialized(vcpu))
> + return -ENODEV;
> +
> + *irq = pmu->irq_num;
> + } else {
> + if (kvm_arm_pmu_initialized(vcpu))
> + return -EBUSY;
> +
> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> + pmu->irq_num = *irq;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> +{
> + int i;
> + struct kvm_vcpu *vcpu;
> + struct kvm *kvm = dev->kvm;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +
> + memset(pmu, 0, sizeof(*pmu));
> + kvm_pmu_vcpu_reset(vcpu);
> + pmu->irq_num = -1;
> + }
> +
> + return 0;
> +}
> +
> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg;
> +
> + if (get_user(reg, uaddr))
> + return -EFAULT;
> +
> + /*
> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> + * VM the interrupt type must be same for each vcpu. As a PPI,
> + * the interrupt number is same for all vcpus, while as a SPI it
> + * must be different for each vcpu.
> + */
> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> + return -EINVAL;
> +
> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + int ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg = -1;
> +
> +
> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> + if (ret)
> + return ret;
> + return put_user(reg, uaddr);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> + return 0;
> + }
> +
> + return -ENXIO;
> +}
> +
> +struct kvm_device_ops kvm_arm_pmu_ops = {
> + .name = "kvm-arm-pmu",
> + .create = kvm_arm_pmu_create,
> + .destroy = kvm_arm_pmu_destroy,
> + .set_attr = kvm_arm_pmu_set_attr,
> + .get_attr = kvm_arm_pmu_get_attr,
> + .has_attr = kvm_arm_pmu_has_attr,
> +};
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 484079e..81a42cc 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> #ifdef CONFIG_KVM_XICS
> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> #endif
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
> +#endif
> };
>
> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
2016-01-07 13:48 ` Marc Zyngier
(?)
@ 2016-01-07 14:00 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:00 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On 2016/1/7 21:48, Marc Zyngier wrote:
>> + if (pmc->perf_event) {
>> > + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
>> > + reg = (pmc->idx == ARMV8_CYCLE_IDX)
>> > + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
>> > + vcpu_sys_reg(vcpu, reg) = counter;
>> > + perf_event_release_kernel(pmc->perf_event);
> I'm having second thoughts about this one. Don't you need to first
> disable the event? You seem to be doing it on the destroy path, and it
> worries me that we're not doing the same thing on both paths.
I didn't find the limitation to use perf_event_release_kernel, but it's
better to disable it before release. Will add.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2016-01-07 14:00 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:00 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, christoffer.dall, linux-arm-kernel, kvm, will.deacon,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On 2016/1/7 21:48, Marc Zyngier wrote:
>> + if (pmc->perf_event) {
>> > + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
>> > + reg = (pmc->idx == ARMV8_CYCLE_IDX)
>> > + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
>> > + vcpu_sys_reg(vcpu, reg) = counter;
>> > + perf_event_release_kernel(pmc->perf_event);
> I'm having second thoughts about this one. Don't you need to first
> disable the event? You seem to be doing it on the destroy path, and it
> worries me that we're not doing the same thing on both paths.
I didn't find the limitation to use perf_event_release_kernel, but it's
better to disable it before release. Will add.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function
@ 2016-01-07 14:00 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:00 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 21:48, Marc Zyngier wrote:
>> + if (pmc->perf_event) {
>> > + counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
>> > + reg = (pmc->idx == ARMV8_CYCLE_IDX)
>> > + ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
>> > + vcpu_sys_reg(vcpu, reg) = counter;
>> > + perf_event_release_kernel(pmc->perf_event);
> I'm having second thoughts about this one. Don't you need to first
> disable the event? You seem to be doing it on the destroy path, and it
> worries me that we're not doing the same thing on both paths.
I didn't find the limitation to use perf_event_release_kernel, but it's
better to disable it before release. Will add.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 14:10 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 14:10 UTC (permalink / raw)
To: Shannon Zhao, kvmarm, christoffer.dall
Cc: linux-arm-kernel, kvm, will.deacon, wei, cov, shannon.zhao,
peter.huangpeng, hangaohuai, Peter Maydell
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> This patchset adds guest PMU support for KVM on ARM64. It takes
> trap-and-emulate approach. When guest wants to monitor one event, it
> will be trapped by KVM and KVM will call perf_event API to create a perf
> event and call relevant perf_event APIs to get the count value of event.
>
> Use perf to test this patchset in guest. When using "perf list", it
> shows the list of the hardware events and hardware cache events perf
> supports. Then use "perf stat -e EVENT" to monitor some event. For
> example, use "perf stat -e cycles" to count cpu cycles and
> "perf stat -e cache-misses" to count cache misses.
I finally feel like we're pretty close to something we could merge. My
current concerns are:
- the 32bit bugs, and the fact that it has obviously not been tested
with a 32bit guest. It would be good to give it a go (you'll probably
have to lie about the nature of the PMU in your QEMU code by pretending
it is a Cortex-A15 PMU, for example).
- The UNDEF path and the patch I've posted today. I've quickly tested
it, and it seems to do the right thing, but this warrant a thorough review.
- I'd like Peter Maydell (cc'd) to give his Ack to the last patch, as we
need the userspace ABI to be agreed upon.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2016-01-07 14:10 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 14:10 UTC (permalink / raw)
To: linux-arm-kernel
On 22/12/15 08:07, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> This patchset adds guest PMU support for KVM on ARM64. It takes
> trap-and-emulate approach. When guest wants to monitor one event, it
> will be trapped by KVM and KVM will call perf_event API to create a perf
> event and call relevant perf_event APIs to get the count value of event.
>
> Use perf to test this patchset in guest. When using "perf list", it
> shows the list of the hardware events and hardware cache events perf
> supports. Then use "perf stat -e EVENT" to monitor some event. For
> example, use "perf stat -e cycles" to count cpu cycles and
> "perf stat -e cache-misses" to count cache misses.
I finally feel like we're pretty close to something we could merge. My
current concerns are:
- the 32bit bugs, and the fact that it has obviously not been tested
with a 32bit guest. It would be good to give it a go (you'll probably
have to lie about the nature of the PMU in your QEMU code by pretending
it is a Cortex-A15 PMU, for example).
- The UNDEF path and the patch I've posted today. I've quickly tested
it, and it seems to do the right thing, but this warrant a thorough review.
- I'd like Peter Maydell (cc'd) to give his Ack to the last patch, as we
need the userspace ABI to be agreed upon.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
2016-01-07 14:10 ` Marc Zyngier
@ 2016-01-07 14:12 ` Will Deacon
-1 siblings, 0 replies; 197+ messages in thread
From: Will Deacon @ 2016-01-07 14:12 UTC (permalink / raw)
To: Marc Zyngier
Cc: Shannon Zhao, kvmarm, christoffer.dall, linux-arm-kernel, kvm,
wei, cov, shannon.zhao, peter.huangpeng, hangaohuai,
Peter Maydell
On Thu, Jan 07, 2016 at 02:10:38PM +0000, Marc Zyngier wrote:
> On 22/12/15 08:07, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > This patchset adds guest PMU support for KVM on ARM64. It takes
> > trap-and-emulate approach. When guest wants to monitor one event, it
> > will be trapped by KVM and KVM will call perf_event API to create a perf
> > event and call relevant perf_event APIs to get the count value of event.
> >
> > Use perf to test this patchset in guest. When using "perf list", it
> > shows the list of the hardware events and hardware cache events perf
> > supports. Then use "perf stat -e EVENT" to monitor some event. For
> > example, use "perf stat -e cycles" to count cpu cycles and
> > "perf stat -e cache-misses" to count cache misses.
>
> I finally feel like we're pretty close to something we could merge. My
> current concerns are:
The merge window opens on Monday and I'm not prepared to take further
PMU changes at this point (unless they're bug fixes, of course).
This needs to wait until 4.6.
Will
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2016-01-07 14:12 ` Will Deacon
0 siblings, 0 replies; 197+ messages in thread
From: Will Deacon @ 2016-01-07 14:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 07, 2016 at 02:10:38PM +0000, Marc Zyngier wrote:
> On 22/12/15 08:07, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > This patchset adds guest PMU support for KVM on ARM64. It takes
> > trap-and-emulate approach. When guest wants to monitor one event, it
> > will be trapped by KVM and KVM will call perf_event API to create a perf
> > event and call relevant perf_event APIs to get the count value of event.
> >
> > Use perf to test this patchset in guest. When using "perf list", it
> > shows the list of the hardware events and hardware cache events perf
> > supports. Then use "perf stat -e EVENT" to monitor some event. For
> > example, use "perf stat -e cycles" to count cpu cycles and
> > "perf stat -e cache-misses" to count cache misses.
>
> I finally feel like we're pretty close to something we could merge. My
> current concerns are:
The merge window opens on Monday and I'm not prepared to take further
PMU changes at this point (unless they're bug fixes, of course).
This needs to wait until 4.6.
Will
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
2016-01-07 14:12 ` Will Deacon
@ 2016-01-07 14:21 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 14:21 UTC (permalink / raw)
To: Will Deacon; +Cc: kvm, shannon.zhao, kvmarm, linux-arm-kernel
On 07/01/16 14:12, Will Deacon wrote:
> On Thu, Jan 07, 2016 at 02:10:38PM +0000, Marc Zyngier wrote:
>> On 22/12/15 08:07, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> This patchset adds guest PMU support for KVM on ARM64. It takes
>>> trap-and-emulate approach. When guest wants to monitor one event, it
>>> will be trapped by KVM and KVM will call perf_event API to create a perf
>>> event and call relevant perf_event APIs to get the count value of event.
>>>
>>> Use perf to test this patchset in guest. When using "perf list", it
>>> shows the list of the hardware events and hardware cache events perf
>>> supports. Then use "perf stat -e EVENT" to monitor some event. For
>>> example, use "perf stat -e cycles" to count cpu cycles and
>>> "perf stat -e cache-misses" to count cache misses.
>>
>> I finally feel like we're pretty close to something we could merge. My
>> current concerns are:
>
> The merge window opens on Monday and I'm not prepared to take further
> PMU changes at this point (unless they're bug fixes, of course).
>
> This needs to wait until 4.6.
Fair enough. I guess I'll continue the review process and queue that
early in the next cycle.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 00/20] KVM: ARM64: Add guest PMU support
@ 2016-01-07 14:21 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-07 14:21 UTC (permalink / raw)
To: linux-arm-kernel
On 07/01/16 14:12, Will Deacon wrote:
> On Thu, Jan 07, 2016 at 02:10:38PM +0000, Marc Zyngier wrote:
>> On 22/12/15 08:07, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> This patchset adds guest PMU support for KVM on ARM64. It takes
>>> trap-and-emulate approach. When guest wants to monitor one event, it
>>> will be trapped by KVM and KVM will call perf_event API to create a perf
>>> event and call relevant perf_event APIs to get the count value of event.
>>>
>>> Use perf to test this patchset in guest. When using "perf list", it
>>> shows the list of the hardware events and hardware cache events perf
>>> supports. Then use "perf stat -e EVENT" to monitor some event. For
>>> example, use "perf stat -e cycles" to count cpu cycles and
>>> "perf stat -e cache-misses" to count cache misses.
>>
>> I finally feel like we're pretty close to something we could merge. My
>> current concerns are:
>
> The merge window opens on Monday and I'm not prepared to take further
> PMU changes at this point (unless they're bug fixes, of course).
>
> This needs to wait until 4.6.
Fair enough. I guess I'll continue the review process and queue that
early in the next cycle.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 13:56 ` Marc Zyngier
(?)
@ 2016-01-07 14:35 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:35 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 2016/1/7 21:56, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> > the kvm_device_ops for it.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> > arch/arm64/include/uapi/asm/kvm.h | 4 +
>> > include/linux/kvm_host.h | 1 +
>> > include/uapi/linux/kvm.h | 2 +
>> > virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> > virt/kvm/kvm_main.c | 4 +
>> > 6 files changed, 163 insertions(+)
>> > create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>> >
>> > diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > new file mode 100644
>> > index 0000000..dda864e
>> > --- /dev/null
>> > +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > @@ -0,0 +1,24 @@
>> > +ARM Virtual Performance Monitor Unit (vPMU)
>> > +===========================================
>> > +
>> > +Device types supported:
>> > + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> > +
>> > +Instantiate one PMU instance for per VCPU through this API.
>> > +
>> > +Groups:
>> > + KVM_DEV_ARM_PMU_GRP_IRQ
>> > + Attributes:
>> > + The attr field of kvm_device_attr encodes one value:
>> > + bits: | 63 .... 32 | 31 .... 0 |
>> > + values: | reserved | vcpu_index |
>> > + A value describing the PMU overflow interrupt number for the specified
>> > + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> > + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> > + same for all vcpus, while as a SPI it must be different for each vcpu.
> I don't see anything enforcing these restrictions in the code (you can
> program different PPIs on each vcpu, or the same SPI everywhere, and
> nothing will generate an error).
>
> Is that something we want to enforce? Or we're happy just to leave it as
> an unsupported corner case?
>
Yeah, it should add the check. How about below check?
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0ccf273..c3347e9 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -435,6 +435,29 @@ static void kvm_arm_pmu_destroy(struct kvm_device *dev)
kfree(dev);
}
+static bool irq_is_invalid(kvm_device *dev, int irq, bool is_ppi)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ if (!kvm_arm_pmu_initialized(vcpu))
+ continue;
+
+ if (is_ppi)
+ if (pmu->irq_num != irq)
+ return true;
+ else
+ if (pmu->irq_num == irq)
+ return true;
+ }
+
+ return false;
+}
+
static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
struct kvm_device_attr *attr)
{
@@ -452,7 +475,8 @@ static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
* the interrupt number is same for all vcpus, while as
a SPI it
* must be different for each vcpu.
*/
- if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs)
+ if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs ||
+ irq_is_invalid(dev, reg, reg < VGIC_NR_PRIVATE_IRQS))
return -EINVAL;
return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
Thanks,
--
Shannon
^ permalink raw reply related [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 14:35 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:35 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, christoffer.dall
Cc: kvm, will.deacon, shannon.zhao, linux-arm-kernel
On 2016/1/7 21:56, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> > the kvm_device_ops for it.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> > arch/arm64/include/uapi/asm/kvm.h | 4 +
>> > include/linux/kvm_host.h | 1 +
>> > include/uapi/linux/kvm.h | 2 +
>> > virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> > virt/kvm/kvm_main.c | 4 +
>> > 6 files changed, 163 insertions(+)
>> > create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>> >
>> > diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > new file mode 100644
>> > index 0000000..dda864e
>> > --- /dev/null
>> > +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > @@ -0,0 +1,24 @@
>> > +ARM Virtual Performance Monitor Unit (vPMU)
>> > +===========================================
>> > +
>> > +Device types supported:
>> > + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> > +
>> > +Instantiate one PMU instance for per VCPU through this API.
>> > +
>> > +Groups:
>> > + KVM_DEV_ARM_PMU_GRP_IRQ
>> > + Attributes:
>> > + The attr field of kvm_device_attr encodes one value:
>> > + bits: | 63 .... 32 | 31 .... 0 |
>> > + values: | reserved | vcpu_index |
>> > + A value describing the PMU overflow interrupt number for the specified
>> > + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> > + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> > + same for all vcpus, while as a SPI it must be different for each vcpu.
> I don't see anything enforcing these restrictions in the code (you can
> program different PPIs on each vcpu, or the same SPI everywhere, and
> nothing will generate an error).
>
> Is that something we want to enforce? Or we're happy just to leave it as
> an unsupported corner case?
>
Yeah, it should add the check. How about below check?
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0ccf273..c3347e9 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -435,6 +435,29 @@ static void kvm_arm_pmu_destroy(struct kvm_device *dev)
kfree(dev);
}
+static bool irq_is_invalid(kvm_device *dev, int irq, bool is_ppi)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ if (!kvm_arm_pmu_initialized(vcpu))
+ continue;
+
+ if (is_ppi)
+ if (pmu->irq_num != irq)
+ return true;
+ else
+ if (pmu->irq_num == irq)
+ return true;
+ }
+
+ return false;
+}
+
static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
struct kvm_device_attr *attr)
{
@@ -452,7 +475,8 @@ static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
* the interrupt number is same for all vcpus, while as
a SPI it
* must be different for each vcpu.
*/
- if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs)
+ if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs ||
+ irq_is_invalid(dev, reg, reg < VGIC_NR_PRIVATE_IRQS))
return -EINVAL;
return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
Thanks,
--
Shannon
^ permalink raw reply related [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 14:35 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 21:56, Marc Zyngier wrote:
> On 22/12/15 08:08, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> > the kvm_device_ops for it.
>> >
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> > Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> > arch/arm64/include/uapi/asm/kvm.h | 4 +
>> > include/linux/kvm_host.h | 1 +
>> > include/uapi/linux/kvm.h | 2 +
>> > virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> > virt/kvm/kvm_main.c | 4 +
>> > 6 files changed, 163 insertions(+)
>> > create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>> >
>> > diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > new file mode 100644
>> > index 0000000..dda864e
>> > --- /dev/null
>> > +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> > @@ -0,0 +1,24 @@
>> > +ARM Virtual Performance Monitor Unit (vPMU)
>> > +===========================================
>> > +
>> > +Device types supported:
>> > + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> > +
>> > +Instantiate one PMU instance for per VCPU through this API.
>> > +
>> > +Groups:
>> > + KVM_DEV_ARM_PMU_GRP_IRQ
>> > + Attributes:
>> > + The attr field of kvm_device_attr encodes one value:
>> > + bits: | 63 .... 32 | 31 .... 0 |
>> > + values: | reserved | vcpu_index |
>> > + A value describing the PMU overflow interrupt number for the specified
>> > + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> > + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> > + same for all vcpus, while as a SPI it must be different for each vcpu.
> I don't see anything enforcing these restrictions in the code (you can
> program different PPIs on each vcpu, or the same SPI everywhere, and
> nothing will generate an error).
>
> Is that something we want to enforce? Or we're happy just to leave it as
> an unsupported corner case?
>
Yeah, it should add the check. How about below check?
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0ccf273..c3347e9 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -435,6 +435,29 @@ static void kvm_arm_pmu_destroy(struct kvm_device *dev)
kfree(dev);
}
+static bool irq_is_invalid(kvm_device *dev, int irq, bool is_ppi)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+ struct kvm *kvm = dev->kvm;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+ if (!kvm_arm_pmu_initialized(vcpu))
+ continue;
+
+ if (is_ppi)
+ if (pmu->irq_num != irq)
+ return true;
+ else
+ if (pmu->irq_num == irq)
+ return true;
+ }
+
+ return false;
+}
+
static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
struct kvm_device_attr *attr)
{
@@ -452,7 +475,8 @@ static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
* the interrupt number is same for all vcpus, while as
a SPI it
* must be different for each vcpu.
*/
- if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs)
+ if (reg < VGIC_NR_SGIS || reg >=
dev->kvm->arch.vgic.nr_irqs ||
+ irq_is_invalid(dev, reg, reg < VGIC_NR_PRIVATE_IRQS))
return -EINVAL;
return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
Thanks,
--
Shannon
^ permalink raw reply related [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 14:36 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-07 14:36 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel, Will Deacon,
Shannon Zhao, arm-mail-list
On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
Do you mean that userspace has to call this API once per vCPU to
create each PMU, or that calling the device create ioctl once makes
the kernel instantiate a PMU for each vCPU?
(It's a little bit confusing that we say "this API" to mean
"not the API documented in this file at all but actually
the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
API docs too.)
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
I see we're using vcpu_index rather than MPIDR affinity value
for specifying which CPU we're configuring. Is this in line with
our planned API for GICv3 configuration?
> + Errors:
> + -ENXIO: Unsupported attribute group
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
What happens if you create a PMU but then never set the IRQ number?
Is there a default or does the VM refuse to run or something?
Do we want an attribute like KVM_DEV_ARM_VGIC_CTRL_INIT so userspace
can say "I have definitely completed configuration of this device now" ?
We wound up with a fair amount of legacy mess to deal with in the
GIC code because we didn't put one of those in from the start.
(Perhaps we should aim to standardize on all kvm devices having one?)
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 14:36 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-07 14:36 UTC (permalink / raw)
To: linux-arm-kernel
On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
Do you mean that userspace has to call this API once per vCPU to
create each PMU, or that calling the device create ioctl once makes
the kernel instantiate a PMU for each vCPU?
(It's a little bit confusing that we say "this API" to mean
"not the API documented in this file at all but actually
the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
API docs too.)
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
I see we're using vcpu_index rather than MPIDR affinity value
for specifying which CPU we're configuring. Is this in line with
our planned API for GICv3 configuration?
> + Errors:
> + -ENXIO: Unsupported attribute group
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
What happens if you create a PMU but then never set the IRQ number?
Is there a default or does the VM refuse to run or something?
Do we want an attribute like KVM_DEV_ARM_VGIC_CTRL_INIT so userspace
can say "I have definitely completed configuration of this device now" ?
We wound up with a fair amount of legacy mess to deal with in the
GIC code because we didn't put one of those in from the start.
(Perhaps we should aim to standardize on all kvm devices having one?)
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 14:36 ` Peter Maydell
@ 2016-01-07 14:49 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:49 UTC (permalink / raw)
To: Peter Maydell
Cc: kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel, Will Deacon,
Shannon Zhao, arm-mail-list
On 2016/1/7 22:36, Peter Maydell wrote:
> On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> the kvm_device_ops for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>> include/linux/kvm_host.h | 1 +
>> include/uapi/linux/kvm.h | 2 +
>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> virt/kvm/kvm_main.c | 4 +
>> 6 files changed, 163 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> new file mode 100644
>> index 0000000..dda864e
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> @@ -0,0 +1,24 @@
>> +ARM Virtual Performance Monitor Unit (vPMU)
>> +===========================================
>> +
>> +Device types supported:
>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> +
>> +Instantiate one PMU instance for per VCPU through this API.
>
> Do you mean that userspace has to call this API once per vCPU to
> create each PMU, or that calling the device create ioctl once makes
> the kernel instantiate a PMU for each vCPU?
>
Call the device create ioctl once and kvm will create a PMU for each
vCPU. But userspace should set the irqs for each PMU since for SPI they
are different.
> (It's a little bit confusing that we say "this API" to mean
> "not the API documented in this file at all but actually
> the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
> API docs too.)
>
>> +
>> +Groups:
>> + KVM_DEV_ARM_PMU_GRP_IRQ
>> + Attributes:
>> + The attr field of kvm_device_attr encodes one value:
>> + bits: | 63 .... 32 | 31 .... 0 |
>> + values: | reserved | vcpu_index |
>> + A value describing the PMU overflow interrupt number for the specified
>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>
> I see we're using vcpu_index rather than MPIDR affinity value
> for specifying which CPU we're configuring. Is this in line with
> our planned API for GICv3 configuration?
>
Here vcpu_index is used to indexing the vCPU, no special use.
>> + Errors:
>> + -ENXIO: Unsupported attribute group
>> + -EBUSY: The PMU overflow interrupt is already set
>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>
> What happens if you create a PMU but then never set the IRQ number?
> Is there a default or does the VM refuse to run or something?
>
If userspace doesn't specify the irq number, the guest will not receive
the PMU interrupt because we check if the irq is initialized when we
inject the interrupt. But guest could still use the vPMU if QEMU
generates a proper DTB or ACPI.
> Do we want an attribute like KVM_DEV_ARM_VGIC_CTRL_INIT so userspace
> can say "I have definitely completed configuration of this device now" ?
>
> We wound up with a fair amount of legacy mess to deal with in the
> GIC code because we didn't put one of those in from the start.
> (Perhaps we should aim to standardize on all kvm devices having one?)
>
> thanks
> -- PMM
>
> .
>
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 14:49 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-07 14:49 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 22:36, Peter Maydell wrote:
> On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> the kvm_device_ops for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>> include/linux/kvm_host.h | 1 +
>> include/uapi/linux/kvm.h | 2 +
>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> virt/kvm/kvm_main.c | 4 +
>> 6 files changed, 163 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> new file mode 100644
>> index 0000000..dda864e
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> @@ -0,0 +1,24 @@
>> +ARM Virtual Performance Monitor Unit (vPMU)
>> +===========================================
>> +
>> +Device types supported:
>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> +
>> +Instantiate one PMU instance for per VCPU through this API.
>
> Do you mean that userspace has to call this API once per vCPU to
> create each PMU, or that calling the device create ioctl once makes
> the kernel instantiate a PMU for each vCPU?
>
Call the device create ioctl once and kvm will create a PMU for each
vCPU. But userspace should set the irqs for each PMU since for SPI they
are different.
> (It's a little bit confusing that we say "this API" to mean
> "not the API documented in this file at all but actually
> the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
> API docs too.)
>
>> +
>> +Groups:
>> + KVM_DEV_ARM_PMU_GRP_IRQ
>> + Attributes:
>> + The attr field of kvm_device_attr encodes one value:
>> + bits: | 63 .... 32 | 31 .... 0 |
>> + values: | reserved | vcpu_index |
>> + A value describing the PMU overflow interrupt number for the specified
>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>
> I see we're using vcpu_index rather than MPIDR affinity value
> for specifying which CPU we're configuring. Is this in line with
> our planned API for GICv3 configuration?
>
Here vcpu_index is used to indexing the vCPU, no special use.
>> + Errors:
>> + -ENXIO: Unsupported attribute group
>> + -EBUSY: The PMU overflow interrupt is already set
>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>
> What happens if you create a PMU but then never set the IRQ number?
> Is there a default or does the VM refuse to run or something?
>
If userspace doesn't specify the irq number, the guest will not receive
the PMU interrupt because we check if the irq is initialized when we
inject the interrupt. But guest could still use the vPMU if QEMU
generates a proper DTB or ACPI.
> Do we want an attribute like KVM_DEV_ARM_VGIC_CTRL_INIT so userspace
> can say "I have definitely completed configuration of this device now" ?
>
> We wound up with a fair amount of legacy mess to deal with in the
> GIC code because we didn't put one of those in from the start.
> (Perhaps we should aim to standardize on all kvm devices having one?)
>
> thanks
> -- PMM
>
> .
>
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 14:49 ` Shannon Zhao
@ 2016-01-07 14:56 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-07 14:56 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel, Will Deacon,
Shannon Zhao, arm-mail-list
On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 22:36, Peter Maydell wrote:
>> On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>>> the kvm_device_ops for it.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>>> include/linux/kvm_host.h | 1 +
>>> include/uapi/linux/kvm.h | 2 +
>>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>>> virt/kvm/kvm_main.c | 4 +
>>> 6 files changed, 163 insertions(+)
>>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>>
>>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>>> new file mode 100644
>>> index 0000000..dda864e
>>> --- /dev/null
>>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>>> @@ -0,0 +1,24 @@
>>> +ARM Virtual Performance Monitor Unit (vPMU)
>>> +===========================================
>>> +
>>> +Device types supported:
>>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>>> +
>>> +Instantiate one PMU instance for per VCPU through this API.
>>
>> Do you mean that userspace has to call this API once per vCPU to
>> create each PMU, or that calling the device create ioctl once makes
>> the kernel instantiate a PMU for each vCPU?
>>
> Call the device create ioctl once and kvm will create a PMU for each
> vCPU. But userspace should set the irqs for each PMU since for SPI they
> are different.
>
>> (It's a little bit confusing that we say "this API" to mean
>> "not the API documented in this file at all but actually
>> the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
>> API docs too.)
>>
>>> +
>>> +Groups:
>>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>> + Attributes:
>>> + The attr field of kvm_device_attr encodes one value:
>>> + bits: | 63 .... 32 | 31 .... 0 |
>>> + values: | reserved | vcpu_index |
>>> + A value describing the PMU overflow interrupt number for the specified
>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>
>> I see we're using vcpu_index rather than MPIDR affinity value
>> for specifying which CPU we're configuring. Is this in line with
>> our planned API for GICv3 configuration?
>>
> Here vcpu_index is used to indexing the vCPU, no special use.
Yes, but you can identify the CPU by index, or by its MPIDR.
We had a discussion about which was the best way for doing
the VGIC API, and I can't remember which way round we ended up
going for. Whichever we chose, we should do the same thing here.
>>> + Errors:
>>> + -ENXIO: Unsupported attribute group
>>> + -EBUSY: The PMU overflow interrupt is already set
>>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>
>> What happens if you create a PMU but then never set the IRQ number?
>> Is there a default or does the VM refuse to run or something?
>>
> If userspace doesn't specify the irq number, the guest will not receive
> the PMU interrupt because we check if the irq is initialized when we
> inject the interrupt. But guest could still use the vPMU if QEMU
> generates a proper DTB or ACPI.
So is it a valid use case to create a PMU with the interrupt not wired
up to anything? (If it's never valid it would be nice to diagnose it
rather than just silently letting the guest run but not work right.)
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 14:56 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-07 14:56 UTC (permalink / raw)
To: linux-arm-kernel
On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 22:36, Peter Maydell wrote:
>> On 22 December 2015 at 08:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>>> the kvm_device_ops for it.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>>> include/linux/kvm_host.h | 1 +
>>> include/uapi/linux/kvm.h | 2 +
>>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>>> virt/kvm/kvm_main.c | 4 +
>>> 6 files changed, 163 insertions(+)
>>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>>
>>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>>> new file mode 100644
>>> index 0000000..dda864e
>>> --- /dev/null
>>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>>> @@ -0,0 +1,24 @@
>>> +ARM Virtual Performance Monitor Unit (vPMU)
>>> +===========================================
>>> +
>>> +Device types supported:
>>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>>> +
>>> +Instantiate one PMU instance for per VCPU through this API.
>>
>> Do you mean that userspace has to call this API once per vCPU to
>> create each PMU, or that calling the device create ioctl once makes
>> the kernel instantiate a PMU for each vCPU?
>>
> Call the device create ioctl once and kvm will create a PMU for each
> vCPU. But userspace should set the irqs for each PMU since for SPI they
> are different.
>
>> (It's a little bit confusing that we say "this API" to mean
>> "not the API documented in this file at all but actually
>> the KVM_CREATE_DEVICE ioctl", but I see we do that in the GIC
>> API docs too.)
>>
>>> +
>>> +Groups:
>>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>> + Attributes:
>>> + The attr field of kvm_device_attr encodes one value:
>>> + bits: | 63 .... 32 | 31 .... 0 |
>>> + values: | reserved | vcpu_index |
>>> + A value describing the PMU overflow interrupt number for the specified
>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>
>> I see we're using vcpu_index rather than MPIDR affinity value
>> for specifying which CPU we're configuring. Is this in line with
>> our planned API for GICv3 configuration?
>>
> Here vcpu_index is used to indexing the vCPU, no special use.
Yes, but you can identify the CPU by index, or by its MPIDR.
We had a discussion about which was the best way for doing
the VGIC API, and I can't remember which way round we ended up
going for. Whichever we chose, we should do the same thing here.
>>> + Errors:
>>> + -ENXIO: Unsupported attribute group
>>> + -EBUSY: The PMU overflow interrupt is already set
>>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>
>> What happens if you create a PMU but then never set the IRQ number?
>> Is there a default or does the VM refuse to run or something?
>>
> If userspace doesn't specify the irq number, the guest will not receive
> the PMU interrupt because we check if the irq is initialized when we
> inject the interrupt. But guest could still use the vPMU if QEMU
> generates a proper DTB or ACPI.
So is it a valid use case to create a PMU with the interrupt not wired
up to anything? (If it's never valid it would be nice to diagnose it
rather than just silently letting the guest run but not work right.)
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
2015-12-22 8:07 ` Shannon Zhao
@ 2016-01-07 19:07 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 19:07 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, Dec 22, 2015 at 04:07:57PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Here we plan to support virtual PMU for guest by full software
> emulation, so define some basic structs and functions preparing for
> futher steps. Define struct kvm_pmc for performance monitor counter and
> struct kvm_pmu for performance monitor unit for each vcpu. According to
> ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
>
> Since this only supports ARM64 (or PMUv3), add a separate config symbol
> for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/kvm/Kconfig | 7 +++++++
> include/kvm/arm_pmu.h | 42 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 51 insertions(+)
> create mode 100644 include/kvm/arm_pmu.h
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 689d4c9..6f0241f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -36,6 +36,7 @@
>
> #include <kvm/arm_vgic.h>
> #include <kvm/arm_arch_timer.h>
> +#include <kvm/arm_pmu.h>
>
> #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
>
> @@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
> /* VGIC state */
> struct vgic_cpu vgic_cpu;
> struct arch_timer_cpu timer_cpu;
> + struct kvm_pmu pmu;
>
> /*
> * Anything that is not used directly from assembly code goes
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a5272c0..de7450d 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -36,6 +36,7 @@ config KVM
> select HAVE_KVM_EVENTFD
> select HAVE_KVM_IRQFD
> select KVM_ARM_VGIC_V3
> + select KVM_ARM_PMU if HW_PERF_EVENTS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> @@ -48,6 +49,12 @@ config KVM_ARM_HOST
> ---help---
> Provides host support for ARM processors.
>
> +config KVM_ARM_PMU
> + bool
> + ---help---
> + Adds support for a virtual Performance Monitoring Unit (PMU) in
> + virtual machines.
> +
> source drivers/vhost/Kconfig
>
> endif # VIRTUALIZATION
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> new file mode 100644
> index 0000000..ddcb5b2
> --- /dev/null
> +++ b/include/kvm/arm_pmu.h
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ASM_ARM_KVM_PMU_H
> +#define __ASM_ARM_KVM_PMU_H
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> +
> +#include <linux/perf_event.h>
> +#include <asm/pmu.h>
> +
> +struct kvm_pmc {
> + u8 idx;/* index into the pmu->pmc array */
> + struct perf_event *perf_event;
> + u64 bitmask;
> +};
> +
> +struct kvm_pmu {
> + /* PMU IRQ Number per VCPU */
This whole structure is per vcpu, so I find the above comment
unnecessary, and even a bit confusing.
> + int irq_num;
> + struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> +};
> +#else
> +struct kvm_pmu {
> +};
> +#endif
> +
> +#endif
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu
@ 2016-01-07 19:07 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 19:07 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 22, 2015 at 04:07:57PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Here we plan to support virtual PMU for guest by full software
> emulation, so define some basic structs and functions preparing for
> futher steps. Define struct kvm_pmc for performance monitor counter and
> struct kvm_pmu for performance monitor unit for each vcpu. According to
> ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.
>
> Since this only supports ARM64 (or PMUv3), add a separate config symbol
> for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/kvm/Kconfig | 7 +++++++
> include/kvm/arm_pmu.h | 42 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 51 insertions(+)
> create mode 100644 include/kvm/arm_pmu.h
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 689d4c9..6f0241f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -36,6 +36,7 @@
>
> #include <kvm/arm_vgic.h>
> #include <kvm/arm_arch_timer.h>
> +#include <kvm/arm_pmu.h>
>
> #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
>
> @@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
> /* VGIC state */
> struct vgic_cpu vgic_cpu;
> struct arch_timer_cpu timer_cpu;
> + struct kvm_pmu pmu;
>
> /*
> * Anything that is not used directly from assembly code goes
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a5272c0..de7450d 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -36,6 +36,7 @@ config KVM
> select HAVE_KVM_EVENTFD
> select HAVE_KVM_IRQFD
> select KVM_ARM_VGIC_V3
> + select KVM_ARM_PMU if HW_PERF_EVENTS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> @@ -48,6 +49,12 @@ config KVM_ARM_HOST
> ---help---
> Provides host support for ARM processors.
>
> +config KVM_ARM_PMU
> + bool
> + ---help---
> + Adds support for a virtual Performance Monitoring Unit (PMU) in
> + virtual machines.
> +
> source drivers/vhost/Kconfig
>
> endif # VIRTUALIZATION
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> new file mode 100644
> index 0000000..ddcb5b2
> --- /dev/null
> +++ b/include/kvm/arm_pmu.h
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ASM_ARM_KVM_PMU_H
> +#define __ASM_ARM_KVM_PMU_H
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> +
> +#include <linux/perf_event.h>
> +#include <asm/pmu.h>
> +
> +struct kvm_pmc {
> + u8 idx;/* index into the pmu->pmc array */
> + struct perf_event *perf_event;
> + u64 bitmask;
> +};
> +
> +struct kvm_pmu {
> + /* PMU IRQ Number per VCPU */
This whole structure is per vcpu, so I find the above comment
unnecessary, and even a bit confusing.
> + int irq_num;
> + struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
> +};
> +#else
> +struct kvm_pmu {
> +};
> +#endif
> +
> +#endif
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 19:17 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 19:17 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvm, marc.zyngier, shannon.zhao, will.deacon, linux-arm-kernel, kvmarm
patch summary nit: s/typer/type/
Thanks,
drew
On Tue, Dec 22, 2015 at 04:08:03PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCFILTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
> + : PMEVTYPER0_EL0 + idx;
> + break;
> + }
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVTYPERn_EL0 register */
> +#define PMU_PMEVTYPER_EL0(n) \
> + /* PMEVTYPERn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
> +
> /*
> * Architected system registers.
> * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
> @@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> - trap_raz_wi },
> + access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> trap_raz_wi },
> @@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVTYPERn_EL0 */
> + PMU_PMEVTYPER_EL0(0),
> + PMU_PMEVTYPER_EL0(1),
> + PMU_PMEVTYPER_EL0(2),
> + PMU_PMEVTYPER_EL0(3),
> + PMU_PMEVTYPER_EL0(4),
> + PMU_PMEVTYPER_EL0(5),
> + PMU_PMEVTYPER_EL0(6),
> + PMU_PMEVTYPER_EL0(7),
> + PMU_PMEVTYPER_EL0(8),
> + PMU_PMEVTYPER_EL0(9),
> + PMU_PMEVTYPER_EL0(10),
> + PMU_PMEVTYPER_EL0(11),
> + PMU_PMEVTYPER_EL0(12),
> + PMU_PMEVTYPER_EL0(13),
> + PMU_PMEVTYPER_EL0(14),
> + PMU_PMEVTYPER_EL0(15),
> + PMU_PMEVTYPER_EL0(16),
> + PMU_PMEVTYPER_EL0(17),
> + PMU_PMEVTYPER_EL0(18),
> + PMU_PMEVTYPER_EL0(19),
> + PMU_PMEVTYPER_EL0(20),
> + PMU_PMEVTYPER_EL0(21),
> + PMU_PMEVTYPER_EL0(22),
> + PMU_PMEVTYPER_EL0(23),
> + PMU_PMEVTYPER_EL0(24),
> + PMU_PMEVTYPER_EL0(25),
> + PMU_PMEVTYPER_EL0(26),
> + PMU_PMEVTYPER_EL0(27),
> + PMU_PMEVTYPER_EL0(28),
> + PMU_PMEVTYPER_EL0(29),
> + PMU_PMEVTYPER_EL0(30),
> + /* PMCCFILTR_EL0
> + * This register resets as unknown in 64bit mode while it resets as zero
> + * in 32bit mode. Here we choose to reset it as zero for consistency.
> + */
> + { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
> + access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
> +
> /* DACR32_EL2 */
> { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
> NULL, reset_unknown, DACR32_EL2 },
> @@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVTYPERn register */
> +#define PMU_PMEVTYPER(n) \
> + /* PMEVTYPERn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper }
> +
> /*
> * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
> * depending on the way they are accessed (as a 32bit or a 64bit
> @@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> @@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
> +
> + /* PMEVTYPERn */
> + PMU_PMEVTYPER(0),
> + PMU_PMEVTYPER(1),
> + PMU_PMEVTYPER(2),
> + PMU_PMEVTYPER(3),
> + PMU_PMEVTYPER(4),
> + PMU_PMEVTYPER(5),
> + PMU_PMEVTYPER(6),
> + PMU_PMEVTYPER(7),
> + PMU_PMEVTYPER(8),
> + PMU_PMEVTYPER(9),
> + PMU_PMEVTYPER(10),
> + PMU_PMEVTYPER(11),
> + PMU_PMEVTYPER(12),
> + PMU_PMEVTYPER(13),
> + PMU_PMEVTYPER(14),
> + PMU_PMEVTYPER(15),
> + PMU_PMEVTYPER(16),
> + PMU_PMEVTYPER(17),
> + PMU_PMEVTYPER(18),
> + PMU_PMEVTYPER(19),
> + PMU_PMEVTYPER(20),
> + PMU_PMEVTYPER(21),
> + PMU_PMEVTYPER(22),
> + PMU_PMEVTYPER(23),
> + PMU_PMEVTYPER(24),
> + PMU_PMEVTYPER(25),
> + PMU_PMEVTYPER(26),
> + PMU_PMEVTYPER(27),
> + PMU_PMEVTYPER(28),
> + PMU_PMEVTYPER(29),
> + PMU_PMEVTYPER(30),
> + /* PMCCFILTR */
> + { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
> };
>
> static const struct sys_reg_desc cp15_64_regs[] = {
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register
@ 2016-01-07 19:17 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 19:17 UTC (permalink / raw)
To: linux-arm-kernel
patch summary nit: s/typer/type/
Thanks,
drew
On Tue, Dec 22, 2015 at 04:08:03PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
> which is mapped to PMEVTYPERn or PMCCFILTR.
>
> The access handler translates all aarch32 register offsets to aarch64
> ones and uses vcpu_sys_reg() to access their values to avoid taking care
> of big endian.
>
> When writing to these registers, create a perf_event for the selected
> event type.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> arch/arm64/kvm/sys_regs.c | 156 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2552db1..ed2939b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -505,6 +505,70 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> return true;
> }
>
> +static inline bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> +{
> + u64 pmcr, val;
> +
> + pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
> + val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
> + if (idx >= val && idx != ARMV8_CYCLE_IDX)
> + return false;
> +
> + return true;
> +}
> +
> +static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 idx, reg;
> +
> + if (r->CRn == 9) {
> + /* PMXEVTYPER_EL0 */
> + reg = 0;
> + } else {
> + if (!p->is_aarch32) {
> + /* PMEVTYPERn_EL0 or PMCCFILTR_EL0 */
> + reg = r->reg;
> + } else {
> + if (r->CRn == 14 && r->CRm == 15 && r->Op2 == 7) {
> + reg = PMCCFILTR_EL0;
> + } else {
> + reg = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> + reg += PMEVTYPER0_EL0;
> + }
> + }
> + }
> +
> + switch (reg) {
> + case PMEVTYPER0_EL0 ... PMEVTYPER30_EL0:
> + idx = reg - PMEVTYPER0_EL0;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> + break;
> + case PMCCFILTR_EL0:
> + idx = ARMV8_CYCLE_IDX;
> + break;
> + default:
> + /* PMXEVTYPER_EL0 */
> + idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
> + if (!pmu_counter_idx_valid(vcpu, idx))
> + return true;
> +
> + reg = (idx == ARMV8_CYCLE_IDX) ? PMCCFILTR_EL0
> + : PMEVTYPER0_EL0 + idx;
> + break;
> + }
> +
> + if (p->is_write) {
> + kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
> + vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
> + } else {
> + p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
> + }
> +
> + return true;
> +}
> +
> /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
> #define DBG_BCR_BVR_WCR_WVR_EL1(n) \
> /* DBGBVRn_EL1 */ \
> @@ -520,6 +584,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> { Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111), \
> trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
>
> +/* Macro to expand the PMEVTYPERn_EL0 register */
> +#define PMU_PMEVTYPER_EL0(n) \
> + /* PMEVTYPERn_EL0 */ \
> + { Op0(0b11), Op1(0b011), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
> +
> /*
> * Architected system registers.
> * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
> @@ -716,7 +787,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> trap_raz_wi },
> /* PMXEVTYPER_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> - trap_raz_wi },
> + access_pmu_evtyper },
> /* PMXEVCNTR_EL0 */
> { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> trap_raz_wi },
> @@ -734,6 +805,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> NULL, reset_unknown, TPIDRRO_EL0 },
>
> + /* PMEVTYPERn_EL0 */
> + PMU_PMEVTYPER_EL0(0),
> + PMU_PMEVTYPER_EL0(1),
> + PMU_PMEVTYPER_EL0(2),
> + PMU_PMEVTYPER_EL0(3),
> + PMU_PMEVTYPER_EL0(4),
> + PMU_PMEVTYPER_EL0(5),
> + PMU_PMEVTYPER_EL0(6),
> + PMU_PMEVTYPER_EL0(7),
> + PMU_PMEVTYPER_EL0(8),
> + PMU_PMEVTYPER_EL0(9),
> + PMU_PMEVTYPER_EL0(10),
> + PMU_PMEVTYPER_EL0(11),
> + PMU_PMEVTYPER_EL0(12),
> + PMU_PMEVTYPER_EL0(13),
> + PMU_PMEVTYPER_EL0(14),
> + PMU_PMEVTYPER_EL0(15),
> + PMU_PMEVTYPER_EL0(16),
> + PMU_PMEVTYPER_EL0(17),
> + PMU_PMEVTYPER_EL0(18),
> + PMU_PMEVTYPER_EL0(19),
> + PMU_PMEVTYPER_EL0(20),
> + PMU_PMEVTYPER_EL0(21),
> + PMU_PMEVTYPER_EL0(22),
> + PMU_PMEVTYPER_EL0(23),
> + PMU_PMEVTYPER_EL0(24),
> + PMU_PMEVTYPER_EL0(25),
> + PMU_PMEVTYPER_EL0(26),
> + PMU_PMEVTYPER_EL0(27),
> + PMU_PMEVTYPER_EL0(28),
> + PMU_PMEVTYPER_EL0(29),
> + PMU_PMEVTYPER_EL0(30),
> + /* PMCCFILTR_EL0
> + * This register resets as unknown in 64bit mode while it resets as zero
> + * in 32bit mode. Here we choose to reset it as zero for consistency.
> + */
> + { Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
> + access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
> +
> /* DACR32_EL2 */
> { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
> NULL, reset_unknown, DACR32_EL2 },
> @@ -923,6 +1033,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
> { Op1( 0), CRm( 2), .access = trap_raz_wi },
> };
>
> +/* Macro to expand the PMEVTYPERn register */
> +#define PMU_PMEVTYPER(n) \
> + /* PMEVTYPERn */ \
> + { Op1(0), CRn(0b1110), \
> + CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)), \
> + access_pmu_evtyper }
> +
> /*
> * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
> * depending on the way they are accessed (as a 32bit or a 64bit
> @@ -959,7 +1076,7 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
> { Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
> { Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
> - { Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
> + { Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
> { Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
> { Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
> @@ -974,6 +1091,41 @@ static const struct sys_reg_desc cp15_regs[] = {
> { Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
>
> { Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
> +
> + /* PMEVTYPERn */
> + PMU_PMEVTYPER(0),
> + PMU_PMEVTYPER(1),
> + PMU_PMEVTYPER(2),
> + PMU_PMEVTYPER(3),
> + PMU_PMEVTYPER(4),
> + PMU_PMEVTYPER(5),
> + PMU_PMEVTYPER(6),
> + PMU_PMEVTYPER(7),
> + PMU_PMEVTYPER(8),
> + PMU_PMEVTYPER(9),
> + PMU_PMEVTYPER(10),
> + PMU_PMEVTYPER(11),
> + PMU_PMEVTYPER(12),
> + PMU_PMEVTYPER(13),
> + PMU_PMEVTYPER(14),
> + PMU_PMEVTYPER(15),
> + PMU_PMEVTYPER(16),
> + PMU_PMEVTYPER(17),
> + PMU_PMEVTYPER(18),
> + PMU_PMEVTYPER(19),
> + PMU_PMEVTYPER(20),
> + PMU_PMEVTYPER(21),
> + PMU_PMEVTYPER(22),
> + PMU_PMEVTYPER(23),
> + PMU_PMEVTYPER(24),
> + PMU_PMEVTYPER(25),
> + PMU_PMEVTYPER(26),
> + PMU_PMEVTYPER(27),
> + PMU_PMEVTYPER(28),
> + PMU_PMEVTYPER(29),
> + PMU_PMEVTYPER(30),
> + /* PMCCFILTR */
> + { Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
> };
>
> static const struct sys_reg_desc cp15_64_regs[] = {
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2015-12-22 8:08 ` Shannon Zhao
@ 2016-01-07 20:18 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 20:18 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
^^ don't need this 'for' here
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
saying that that's good, but expanding it to 32 bits here is
inconsistent. (A side note is that I think we should s/vcpu_index/vcpu_id/
in order to keep the parameter name consistent with what's used by
KVM_CREATE_VCPU)
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
> +
> + Errors:
> + -ENXIO: Unsupported attribute group
Do we need to specify ENXIO here? It's already specified in
Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2d4ca4b..cbb9022 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> +/* Device Control API: ARM PMU */
> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
I don't think we should need a mask like this, at least not in the uapi.
The documentation says to use a vcpu-index [really a vcpu-id], and users
should know how to convert their vcpu handle (whatever that may be) to
a vcpu-id using whatever transformation is necessary. They may already
have a "vcpu id mask" defined (this is one reason why I don't think we
should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
everywhere else). Likewise, kvm should know how to do it's transformation.
Maybe, to aid in the attr field construction, we should supply a shift,
allowing both sides to do something like
int pmu_attr_extract_vcpu_id(u64 attr)
{
return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
}
u64 pmu_attr_create(int vcpu_id)
{
return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
}
But, in this case the shift is zero, so it's not really necessary. In
any case, please add the 'V' for VCPU.
> +
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c923350..608dea6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> extern struct kvm_device_ops kvm_xics_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 03f3618..4ba6fdd 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> KVM_DEV_TYPE_ARM_VGIC_V3,
> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> + KVM_DEV_TYPE_ARM_PMU_V3,
> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 3ec3cdd..5518308 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -19,6 +19,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <linux/perf_event.h>
> +#include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> #include <kvm/arm_vgic.h>
> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>
> pmc->perf_event = event;
> }
> +
> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.pmu.irq_num != -1;
> +}
> +
> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> + int *irq, bool is_set)
> +{
> + int cpuid;
please call this vcpu_id
> + struct kvm_vcpu *vcpu;
> + struct kvm_pmu *pmu;
> +
> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> + return -EINVAL;
> +
> + vcpu = kvm_get_vcpu(kvm, cpuid);
> + if (!vcpu)
> + return -EINVAL;
> +
> + pmu = &vcpu->arch.pmu;
> + if (!is_set) {
> + if (!kvm_arm_pmu_initialized(vcpu))
> + return -ENODEV;
> +
> + *irq = pmu->irq_num;
> + } else {
> + if (kvm_arm_pmu_initialized(vcpu))
> + return -EBUSY;
> +
> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> + pmu->irq_num = *irq;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> +{
> + int i;
> + struct kvm_vcpu *vcpu;
> + struct kvm *kvm = dev->kvm;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +
> + memset(pmu, 0, sizeof(*pmu));
I don't think we want this memset. If we can only create the pmu
once, then it's unnecessary (we zalloc vcpus). And, if we can
recreate pmus with this call, then it'll create a memory leak, as
we'll be zero-ing out all the perf_event pointers, and then won't
be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
we need to make sure we're NULL-ing them after each free instead.
> + kvm_pmu_vcpu_reset(vcpu);
> + pmu->irq_num = -1;
> + }
> +
> + return 0;
> +}
> +
> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg;
> +
> + if (get_user(reg, uaddr))
> + return -EFAULT;
> +
> + /*
> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> + * VM the interrupt type must be same for each vcpu. As a PPI,
> + * the interrupt number is same for all vcpus, while as a SPI it
> + * must be different for each vcpu.
> + */
> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> + return -EINVAL;
> +
> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + int ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg = -1;
> +
> +
> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> + if (ret)
> + return ret;
> + return put_user(reg, uaddr);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> + return 0;
> + }
> +
> + return -ENXIO;
> +}
> +
> +struct kvm_device_ops kvm_arm_pmu_ops = {
> + .name = "kvm-arm-pmu",
> + .create = kvm_arm_pmu_create,
> + .destroy = kvm_arm_pmu_destroy,
> + .set_attr = kvm_arm_pmu_set_attr,
> + .get_attr = kvm_arm_pmu_get_attr,
> + .has_attr = kvm_arm_pmu_has_attr,
> +};
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 484079e..81a42cc 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> #ifdef CONFIG_KVM_XICS
> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> #endif
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
device type name?
> +#endif
> };
>
> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
> --
> 2.0.4
>
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 20:18 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 20:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 4 +
> 6 files changed, 163 insertions(+)
> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>
> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> new file mode 100644
> index 0000000..dda864e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> @@ -0,0 +1,24 @@
> +ARM Virtual Performance Monitor Unit (vPMU)
> +===========================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> +
> +Instantiate one PMU instance for per VCPU through this API.
^^ don't need this 'for' here
> +
> +Groups:
> + KVM_DEV_ARM_PMU_GRP_IRQ
> + Attributes:
> + The attr field of kvm_device_attr encodes one value:
> + bits: | 63 .... 32 | 31 .... 0 |
> + values: | reserved | vcpu_index |
Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
saying that that's good, but expanding it to 32 bits here is
inconsistent. (A side note is that I think we should s/vcpu_index/vcpu_id/
in order to keep the parameter name consistent with what's used by
KVM_CREATE_VCPU)
> + A value describing the PMU overflow interrupt number for the specified
> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> + same for all vcpus, while as a SPI it must be different for each vcpu.
> +
> + Errors:
> + -ENXIO: Unsupported attribute group
Do we need to specify ENXIO here? It's already specified in
Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
> + -EBUSY: The PMU overflow interrupt is already set
> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2d4ca4b..cbb9022 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> +/* Device Control API: ARM PMU */
> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
I don't think we should need a mask like this, at least not in the uapi.
The documentation says to use a vcpu-index [really a vcpu-id], and users
should know how to convert their vcpu handle (whatever that may be) to
a vcpu-id using whatever transformation is necessary. They may already
have a "vcpu id mask" defined (this is one reason why I don't think we
should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
everywhere else). Likewise, kvm should know how to do it's transformation.
Maybe, to aid in the attr field construction, we should supply a shift,
allowing both sides to do something like
int pmu_attr_extract_vcpu_id(u64 attr)
{
return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
}
u64 pmu_attr_create(int vcpu_id)
{
return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
}
But, in this case the shift is zero, so it's not really necessary. In
any case, please add the 'V' for VCPU.
> +
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c923350..608dea6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> extern struct kvm_device_ops kvm_xics_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 03f3618..4ba6fdd 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> KVM_DEV_TYPE_ARM_VGIC_V3,
> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> + KVM_DEV_TYPE_ARM_PMU_V3,
> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 3ec3cdd..5518308 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -19,6 +19,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <linux/perf_event.h>
> +#include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> #include <kvm/arm_vgic.h>
> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>
> pmc->perf_event = event;
> }
> +
> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.pmu.irq_num != -1;
> +}
> +
> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> + int *irq, bool is_set)
> +{
> + int cpuid;
please call this vcpu_id
> + struct kvm_vcpu *vcpu;
> + struct kvm_pmu *pmu;
> +
> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> + return -EINVAL;
> +
> + vcpu = kvm_get_vcpu(kvm, cpuid);
> + if (!vcpu)
> + return -EINVAL;
> +
> + pmu = &vcpu->arch.pmu;
> + if (!is_set) {
> + if (!kvm_arm_pmu_initialized(vcpu))
> + return -ENODEV;
> +
> + *irq = pmu->irq_num;
> + } else {
> + if (kvm_arm_pmu_initialized(vcpu))
> + return -EBUSY;
> +
> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> + pmu->irq_num = *irq;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> +{
> + int i;
> + struct kvm_vcpu *vcpu;
> + struct kvm *kvm = dev->kvm;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +
> + memset(pmu, 0, sizeof(*pmu));
I don't think we want this memset. If we can only create the pmu
once, then it's unnecessary (we zalloc vcpus). And, if we can
recreate pmus with this call, then it'll create a memory leak, as
we'll be zero-ing out all the perf_event pointers, and then won't
be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
we need to make sure we're NULL-ing them after each free instead.
> + kvm_pmu_vcpu_reset(vcpu);
> + pmu->irq_num = -1;
> + }
> +
> + return 0;
> +}
> +
> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg;
> +
> + if (get_user(reg, uaddr))
> + return -EFAULT;
> +
> + /*
> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> + * VM the interrupt type must be same for each vcpu. As a PPI,
> + * the interrupt number is same for all vcpus, while as a SPI it
> + * must be different for each vcpu.
> + */
> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> + return -EINVAL;
> +
> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + int ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> + int __user *uaddr = (int __user *)(long)attr->addr;
> + int reg = -1;
> +
> +
> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> + if (ret)
> + return ret;
> + return put_user(reg, uaddr);
> + }
> + }
> +
> + return -ENXIO;
> +}
> +
> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> + return 0;
> + }
> +
> + return -ENXIO;
> +}
> +
> +struct kvm_device_ops kvm_arm_pmu_ops = {
> + .name = "kvm-arm-pmu",
> + .create = kvm_arm_pmu_create,
> + .destroy = kvm_arm_pmu_destroy,
> + .set_attr = kvm_arm_pmu_set_attr,
> + .get_attr = kvm_arm_pmu_get_attr,
> + .has_attr = kvm_arm_pmu_has_attr,
> +};
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 484079e..81a42cc 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> #ifdef CONFIG_KVM_XICS
> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> #endif
> +
> +#ifdef CONFIG_KVM_ARM_PMU
> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
device type name?
> +#endif
> };
>
> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
> --
> 2.0.4
>
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 14:56 ` Peter Maydell
@ 2016-01-07 20:36 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 20:36 UTC (permalink / raw)
To: Peter Maydell
Cc: Shannon Zhao, kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> >>> +
> >>> +Groups:
> >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> >>> + Attributes:
> >>> + The attr field of kvm_device_attr encodes one value:
> >>> + bits: | 63 .... 32 | 31 .... 0 |
> >>> + values: | reserved | vcpu_index |
> >>> + A value describing the PMU overflow interrupt number for the specified
> >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >>
> >> I see we're using vcpu_index rather than MPIDR affinity value
> >> for specifying which CPU we're configuring. Is this in line with
> >> our planned API for GICv3 configuration?
> >>
> > Here vcpu_index is used to indexing the vCPU, no special use.
>
> Yes, but you can identify the CPU by index, or by its MPIDR.
> We had a discussion about which was the best way for doing
> the VGIC API, and I can't remember which way round we ended up
> going for. Whichever we chose, we should do the same thing here.
I think we should start up a new discussion on this. My understanding,
after a chat with Igor, who was involved in the untangling of vcpu-id and
apic-id for x86, is that using vcpu-id is preferred, unless of course
the device expects an apic-id/mpidr, in which case there's no reason to
translate it on both sides.
Other things to discuss are
1) Consistent use of the term vcpu-id vs. vcpu-index in the documentation.
I just brought that up in my last reply to this patch.
2) Extending a vcpu-index [id] beyond 8-bits.
3) Should vcpu-ids be reusable after hotunplugging them?
4) Devices like this pmu and the vgic have some global (all vcpus wide)
properties, but then also vcpu specific registers, which require the
vcpu-index parameter. Should we instead create a "vcpu device ioctl"
for these? I.e. extend SET/GET_DEVICE_ATTR to also be of type
'vcpu ioctl', allowing the vcpu-index parameter to be dropped?
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-07 20:36 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-07 20:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> >>> +
> >>> +Groups:
> >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> >>> + Attributes:
> >>> + The attr field of kvm_device_attr encodes one value:
> >>> + bits: | 63 .... 32 | 31 .... 0 |
> >>> + values: | reserved | vcpu_index |
> >>> + A value describing the PMU overflow interrupt number for the specified
> >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >>
> >> I see we're using vcpu_index rather than MPIDR affinity value
> >> for specifying which CPU we're configuring. Is this in line with
> >> our planned API for GICv3 configuration?
> >>
> > Here vcpu_index is used to indexing the vCPU, no special use.
>
> Yes, but you can identify the CPU by index, or by its MPIDR.
> We had a discussion about which was the best way for doing
> the VGIC API, and I can't remember which way round we ended up
> going for. Whichever we chose, we should do the same thing here.
I think we should start up a new discussion on this. My understanding,
after a chat with Igor, who was involved in the untangling of vcpu-id and
apic-id for x86, is that using vcpu-id is preferred, unless of course
the device expects an apic-id/mpidr, in which case there's no reason to
translate it on both sides.
Other things to discuss are
1) Consistent use of the term vcpu-id vs. vcpu-index in the documentation.
I just brought that up in my last reply to this patch.
2) Extending a vcpu-index [id] beyond 8-bits.
3) Should vcpu-ids be reusable after hotunplugging them?
4) Devices like this pmu and the vgic have some global (all vcpus wide)
properties, but then also vcpu specific registers, which require the
vcpu-index parameter. Should we instead create a "vcpu device ioctl"
for these? I.e. extend SET/GET_DEVICE_ATTR to also be of type
'vcpu ioctl', allowing the vcpu-index parameter to be dropped?
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 20:18 ` Andrew Jones
(?)
@ 2016-01-08 2:53 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 2:53 UTC (permalink / raw)
To: Andrew Jones
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On 2016/1/8 4:18, Andrew Jones wrote:
> On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> the kvm_device_ops for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>> include/linux/kvm_host.h | 1 +
>> include/uapi/linux/kvm.h | 2 +
>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> virt/kvm/kvm_main.c | 4 +
>> 6 files changed, 163 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> new file mode 100644
>> index 0000000..dda864e
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> @@ -0,0 +1,24 @@
>> +ARM Virtual Performance Monitor Unit (vPMU)
>> +===========================================
>> +
>> +Device types supported:
>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> +
>> +Instantiate one PMU instance for per VCPU through this API.
> ^^ don't need this 'for' here
>
>> +
>> +Groups:
>> + KVM_DEV_ARM_PMU_GRP_IRQ
>> + Attributes:
>> + The attr field of kvm_device_attr encodes one value:
>> + bits: | 63 .... 32 | 31 .... 0 |
>> + values: | reserved | vcpu_index |
>
> Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
> saying that that's good, but expanding it to 32 bits here is
> inconsistent.
Expand it to 32 bits just in case it needs to support more than 256
vcpus in the future. If you think this is not good, I'll change it to 8
bits.
(A side note is that I think we should s/vcpu_index/vcpu_id/
> in order to keep the parameter name consistent with what's used by
> KVM_CREATE_VCPU)
>
Eh, I make it consistent with vGIC which is a kvm device that's also
created via KVM_CREATE_DEVICE API. So they are different names but
express same thing.
>> + A value describing the PMU overflow interrupt number for the specified
>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>> +
>> + Errors:
>> + -ENXIO: Unsupported attribute group
>
> Do we need to specify ENXIO here? It's already specified in
> Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
>
But specifying it here is not bad, right? If you insist on this, I'll
drop it.
>> + -EBUSY: The PMU overflow interrupt is already set
>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 2d4ca4b..cbb9022 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
>> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> +/* Device Control API: ARM PMU */
>> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
>> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
>
> I don't think we should need a mask like this, at least not in the uapi.
> The documentation says to use a vcpu-index [really a vcpu-id], and users
> should know how to convert their vcpu handle (whatever that may be) to
> a vcpu-id using whatever transformation is necessary. They may already
> have a "vcpu id mask" defined (this is one reason why I don't think we
> should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
> everywhere else). Likewise, kvm should know how to do it's transformation.
> Maybe, to aid in the attr field construction, we should supply a shift,
> allowing both sides to do something like
>
> int pmu_attr_extract_vcpu_id(u64 attr)
> {
> return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
So what's the value of the VCPU_ID_MASK? I didn't see any definitions
about it. It looks like KVM_DEV_ARM_PMU_CPUID_MASK(just has a difference
between 32 bits and 8 bits)
> }
>
> u64 pmu_attr_create(int vcpu_id)
> {
> return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
> }
>
> But, in this case the shift is zero, so it's not really necessary. In
> any case, please add the 'V' for VCPU.
>
>> +
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> #define KVM_ARM_IRQ_TYPE_MASK 0xff
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index c923350..608dea6 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
>> extern struct kvm_device_ops kvm_xics_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
>> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>>
>> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 03f3618..4ba6fdd 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
>> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
>> KVM_DEV_TYPE_ARM_VGIC_V3,
>> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
>> + KVM_DEV_TYPE_ARM_PMU_V3,
>> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
>> KVM_DEV_TYPE_MAX,
>> };
>>
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index 3ec3cdd..5518308 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -19,6 +19,7 @@
>> #include <linux/kvm.h>
>> #include <linux/kvm_host.h>
>> #include <linux/perf_event.h>
>> +#include <linux/uaccess.h>
>> #include <asm/kvm_emulate.h>
>> #include <kvm/arm_pmu.h>
>> #include <kvm/arm_vgic.h>
>> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>
>> pmc->perf_event = event;
>> }
>> +
>> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
>> +{
>> + return vcpu->arch.pmu.irq_num != -1;
>> +}
>> +
>> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
>> + int *irq, bool is_set)
>> +{
>> + int cpuid;
>
> please call this vcpu_id
>
>> + struct kvm_vcpu *vcpu;
>> + struct kvm_pmu *pmu;
>> +
>> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
>> + if (cpuid >= atomic_read(&kvm->online_vcpus))
>> + return -EINVAL;
>> +
>> + vcpu = kvm_get_vcpu(kvm, cpuid);
>> + if (!vcpu)
>> + return -EINVAL;
>> +
>> + pmu = &vcpu->arch.pmu;
>> + if (!is_set) {
>> + if (!kvm_arm_pmu_initialized(vcpu))
>> + return -ENODEV;
>> +
>> + *irq = pmu->irq_num;
>> + } else {
>> + if (kvm_arm_pmu_initialized(vcpu))
>> + return -EBUSY;
>> +
>> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
>> + pmu->irq_num = *irq;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
>> +{
>> + int i;
>> + struct kvm_vcpu *vcpu;
>> + struct kvm *kvm = dev->kvm;
>> +
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +
>> + memset(pmu, 0, sizeof(*pmu));
>
> I don't think we want this memset. If we can only create the pmu
> once, then it's unnecessary (we zalloc vcpus). And, if we can
> recreate pmus with this call, then it'll create a memory leak, as
> we'll be zero-ing out all the perf_event pointers, and then won't
> be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
> we need to make sure we're NULL-ing them after each free instead.
>
Ok, will drop this.
>> + kvm_pmu_vcpu_reset(vcpu);
>> + pmu->irq_num = -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
>> +{
>> + kfree(dev);
>> +}
>> +
>> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg;
>> +
>> + if (get_user(reg, uaddr))
>> + return -EFAULT;
>> +
>> + /*
>> + * The PMU overflow interrupt could be a PPI or SPI, but for one
>> + * VM the interrupt type must be same for each vcpu. As a PPI,
>> + * the interrupt number is same for all vcpus, while as a SPI it
>> + * must be different for each vcpu.
>> + */
>> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
>> + return -EINVAL;
>> +
>> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + int ret;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg = -1;
>> +
>> +
>> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
>> + if (ret)
>> + return ret;
>> + return put_user(reg, uaddr);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ:
>> + return 0;
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +struct kvm_device_ops kvm_arm_pmu_ops = {
>> + .name = "kvm-arm-pmu",
>> + .create = kvm_arm_pmu_create,
>> + .destroy = kvm_arm_pmu_destroy,
>> + .set_attr = kvm_arm_pmu_set_attr,
>> + .get_attr = kvm_arm_pmu_get_attr,
>> + .has_attr = kvm_arm_pmu_has_attr,
>> +};
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 484079e..81a42cc 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
>> #ifdef CONFIG_KVM_XICS
>> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
>> #endif
>> +
>> +#ifdef CONFIG_KVM_ARM_PMU
>> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
>
> Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
> device type name?
>
Sure, will add.
>> +#endif
>> };
>>
>> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>> --
>> 2.0.4
>>
>
> Thanks,
> drew
>
> .
>
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 2:53 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 2:53 UTC (permalink / raw)
To: Andrew Jones
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On 2016/1/8 4:18, Andrew Jones wrote:
> On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> the kvm_device_ops for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>> include/linux/kvm_host.h | 1 +
>> include/uapi/linux/kvm.h | 2 +
>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> virt/kvm/kvm_main.c | 4 +
>> 6 files changed, 163 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> new file mode 100644
>> index 0000000..dda864e
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> @@ -0,0 +1,24 @@
>> +ARM Virtual Performance Monitor Unit (vPMU)
>> +===========================================
>> +
>> +Device types supported:
>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> +
>> +Instantiate one PMU instance for per VCPU through this API.
> ^^ don't need this 'for' here
>
>> +
>> +Groups:
>> + KVM_DEV_ARM_PMU_GRP_IRQ
>> + Attributes:
>> + The attr field of kvm_device_attr encodes one value:
>> + bits: | 63 .... 32 | 31 .... 0 |
>> + values: | reserved | vcpu_index |
>
> Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
> saying that that's good, but expanding it to 32 bits here is
> inconsistent.
Expand it to 32 bits just in case it needs to support more than 256
vcpus in the future. If you think this is not good, I'll change it to 8
bits.
(A side note is that I think we should s/vcpu_index/vcpu_id/
> in order to keep the parameter name consistent with what's used by
> KVM_CREATE_VCPU)
>
Eh, I make it consistent with vGIC which is a kvm device that's also
created via KVM_CREATE_DEVICE API. So they are different names but
express same thing.
>> + A value describing the PMU overflow interrupt number for the specified
>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>> +
>> + Errors:
>> + -ENXIO: Unsupported attribute group
>
> Do we need to specify ENXIO here? It's already specified in
> Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
>
But specifying it here is not bad, right? If you insist on this, I'll
drop it.
>> + -EBUSY: The PMU overflow interrupt is already set
>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 2d4ca4b..cbb9022 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
>> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> +/* Device Control API: ARM PMU */
>> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
>> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
>
> I don't think we should need a mask like this, at least not in the uapi.
> The documentation says to use a vcpu-index [really a vcpu-id], and users
> should know how to convert their vcpu handle (whatever that may be) to
> a vcpu-id using whatever transformation is necessary. They may already
> have a "vcpu id mask" defined (this is one reason why I don't think we
> should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
> everywhere else). Likewise, kvm should know how to do it's transformation.
> Maybe, to aid in the attr field construction, we should supply a shift,
> allowing both sides to do something like
>
> int pmu_attr_extract_vcpu_id(u64 attr)
> {
> return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
So what's the value of the VCPU_ID_MASK? I didn't see any definitions
about it. It looks like KVM_DEV_ARM_PMU_CPUID_MASK(just has a difference
between 32 bits and 8 bits)
> }
>
> u64 pmu_attr_create(int vcpu_id)
> {
> return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
> }
>
> But, in this case the shift is zero, so it's not really necessary. In
> any case, please add the 'V' for VCPU.
>
>> +
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> #define KVM_ARM_IRQ_TYPE_MASK 0xff
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index c923350..608dea6 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
>> extern struct kvm_device_ops kvm_xics_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
>> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>>
>> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 03f3618..4ba6fdd 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
>> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
>> KVM_DEV_TYPE_ARM_VGIC_V3,
>> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
>> + KVM_DEV_TYPE_ARM_PMU_V3,
>> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
>> KVM_DEV_TYPE_MAX,
>> };
>>
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index 3ec3cdd..5518308 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -19,6 +19,7 @@
>> #include <linux/kvm.h>
>> #include <linux/kvm_host.h>
>> #include <linux/perf_event.h>
>> +#include <linux/uaccess.h>
>> #include <asm/kvm_emulate.h>
>> #include <kvm/arm_pmu.h>
>> #include <kvm/arm_vgic.h>
>> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>
>> pmc->perf_event = event;
>> }
>> +
>> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
>> +{
>> + return vcpu->arch.pmu.irq_num != -1;
>> +}
>> +
>> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
>> + int *irq, bool is_set)
>> +{
>> + int cpuid;
>
> please call this vcpu_id
>
>> + struct kvm_vcpu *vcpu;
>> + struct kvm_pmu *pmu;
>> +
>> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
>> + if (cpuid >= atomic_read(&kvm->online_vcpus))
>> + return -EINVAL;
>> +
>> + vcpu = kvm_get_vcpu(kvm, cpuid);
>> + if (!vcpu)
>> + return -EINVAL;
>> +
>> + pmu = &vcpu->arch.pmu;
>> + if (!is_set) {
>> + if (!kvm_arm_pmu_initialized(vcpu))
>> + return -ENODEV;
>> +
>> + *irq = pmu->irq_num;
>> + } else {
>> + if (kvm_arm_pmu_initialized(vcpu))
>> + return -EBUSY;
>> +
>> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
>> + pmu->irq_num = *irq;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
>> +{
>> + int i;
>> + struct kvm_vcpu *vcpu;
>> + struct kvm *kvm = dev->kvm;
>> +
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +
>> + memset(pmu, 0, sizeof(*pmu));
>
> I don't think we want this memset. If we can only create the pmu
> once, then it's unnecessary (we zalloc vcpus). And, if we can
> recreate pmus with this call, then it'll create a memory leak, as
> we'll be zero-ing out all the perf_event pointers, and then won't
> be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
> we need to make sure we're NULL-ing them after each free instead.
>
Ok, will drop this.
>> + kvm_pmu_vcpu_reset(vcpu);
>> + pmu->irq_num = -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
>> +{
>> + kfree(dev);
>> +}
>> +
>> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg;
>> +
>> + if (get_user(reg, uaddr))
>> + return -EFAULT;
>> +
>> + /*
>> + * The PMU overflow interrupt could be a PPI or SPI, but for one
>> + * VM the interrupt type must be same for each vcpu. As a PPI,
>> + * the interrupt number is same for all vcpus, while as a SPI it
>> + * must be different for each vcpu.
>> + */
>> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
>> + return -EINVAL;
>> +
>> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + int ret;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg = -1;
>> +
>> +
>> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
>> + if (ret)
>> + return ret;
>> + return put_user(reg, uaddr);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ:
>> + return 0;
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +struct kvm_device_ops kvm_arm_pmu_ops = {
>> + .name = "kvm-arm-pmu",
>> + .create = kvm_arm_pmu_create,
>> + .destroy = kvm_arm_pmu_destroy,
>> + .set_attr = kvm_arm_pmu_set_attr,
>> + .get_attr = kvm_arm_pmu_get_attr,
>> + .has_attr = kvm_arm_pmu_has_attr,
>> +};
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 484079e..81a42cc 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
>> #ifdef CONFIG_KVM_XICS
>> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
>> #endif
>> +
>> +#ifdef CONFIG_KVM_ARM_PMU
>> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
>
> Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
> device type name?
>
Sure, will add.
>> +#endif
>> };
>>
>> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>> --
>> 2.0.4
>>
>
> Thanks,
> drew
>
> .
>
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 2:53 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 2:53 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/8 4:18, Andrew Jones wrote:
> On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
>> the kvm_device_ops for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
>> arch/arm64/include/uapi/asm/kvm.h | 4 +
>> include/linux/kvm_host.h | 1 +
>> include/uapi/linux/kvm.h | 2 +
>> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
>> virt/kvm/kvm_main.c | 4 +
>> 6 files changed, 163 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> new file mode 100644
>> index 0000000..dda864e
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
>> @@ -0,0 +1,24 @@
>> +ARM Virtual Performance Monitor Unit (vPMU)
>> +===========================================
>> +
>> +Device types supported:
>> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
>> +
>> +Instantiate one PMU instance for per VCPU through this API.
> ^^ don't need this 'for' here
>
>> +
>> +Groups:
>> + KVM_DEV_ARM_PMU_GRP_IRQ
>> + Attributes:
>> + The attr field of kvm_device_attr encodes one value:
>> + bits: | 63 .... 32 | 31 .... 0 |
>> + values: | reserved | vcpu_index |
>
> Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
> saying that that's good, but expanding it to 32 bits here is
> inconsistent.
Expand it to 32 bits just in case it needs to support more than 256
vcpus in the future. If you think this is not good, I'll change it to 8
bits.
(A side note is that I think we should s/vcpu_index/vcpu_id/
> in order to keep the parameter name consistent with what's used by
> KVM_CREATE_VCPU)
>
Eh, I make it consistent with vGIC which is a kvm device that's also
created via KVM_CREATE_DEVICE API. So they are different names but
express same thing.
>> + A value describing the PMU overflow interrupt number for the specified
>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>> +
>> + Errors:
>> + -ENXIO: Unsupported attribute group
>
> Do we need to specify ENXIO here? It's already specified in
> Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
>
But specifying it here is not bad, right? If you insist on this, I'll
drop it.
>> + -EBUSY: The PMU overflow interrupt is already set
>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 2d4ca4b..cbb9022 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
>> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> +/* Device Control API: ARM PMU */
>> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
>> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
>
> I don't think we should need a mask like this, at least not in the uapi.
> The documentation says to use a vcpu-index [really a vcpu-id], and users
> should know how to convert their vcpu handle (whatever that may be) to
> a vcpu-id using whatever transformation is necessary. They may already
> have a "vcpu id mask" defined (this is one reason why I don't think we
> should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
> everywhere else). Likewise, kvm should know how to do it's transformation.
> Maybe, to aid in the attr field construction, we should supply a shift,
> allowing both sides to do something like
>
> int pmu_attr_extract_vcpu_id(u64 attr)
> {
> return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
So what's the value of the VCPU_ID_MASK? I didn't see any definitions
about it. It looks like KVM_DEV_ARM_PMU_CPUID_MASK(just has a difference
between 32 bits and 8 bits)
> }
>
> u64 pmu_attr_create(int vcpu_id)
> {
> return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
> }
>
> But, in this case the shift is zero, so it's not really necessary. In
> any case, please add the 'V' for VCPU.
>
>> +
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> #define KVM_ARM_IRQ_TYPE_MASK 0xff
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index c923350..608dea6 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
>> extern struct kvm_device_ops kvm_xics_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
>> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
>> +extern struct kvm_device_ops kvm_arm_pmu_ops;
>>
>> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 03f3618..4ba6fdd 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
>> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
>> KVM_DEV_TYPE_ARM_VGIC_V3,
>> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
>> + KVM_DEV_TYPE_ARM_PMU_V3,
>> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
>> KVM_DEV_TYPE_MAX,
>> };
>>
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index 3ec3cdd..5518308 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -19,6 +19,7 @@
>> #include <linux/kvm.h>
>> #include <linux/kvm_host.h>
>> #include <linux/perf_event.h>
>> +#include <linux/uaccess.h>
>> #include <asm/kvm_emulate.h>
>> #include <kvm/arm_pmu.h>
>> #include <kvm/arm_vgic.h>
>> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>
>> pmc->perf_event = event;
>> }
>> +
>> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
>> +{
>> + return vcpu->arch.pmu.irq_num != -1;
>> +}
>> +
>> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
>> + int *irq, bool is_set)
>> +{
>> + int cpuid;
>
> please call this vcpu_id
>
>> + struct kvm_vcpu *vcpu;
>> + struct kvm_pmu *pmu;
>> +
>> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
>> + if (cpuid >= atomic_read(&kvm->online_vcpus))
>> + return -EINVAL;
>> +
>> + vcpu = kvm_get_vcpu(kvm, cpuid);
>> + if (!vcpu)
>> + return -EINVAL;
>> +
>> + pmu = &vcpu->arch.pmu;
>> + if (!is_set) {
>> + if (!kvm_arm_pmu_initialized(vcpu))
>> + return -ENODEV;
>> +
>> + *irq = pmu->irq_num;
>> + } else {
>> + if (kvm_arm_pmu_initialized(vcpu))
>> + return -EBUSY;
>> +
>> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
>> + pmu->irq_num = *irq;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
>> +{
>> + int i;
>> + struct kvm_vcpu *vcpu;
>> + struct kvm *kvm = dev->kvm;
>> +
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +
>> + memset(pmu, 0, sizeof(*pmu));
>
> I don't think we want this memset. If we can only create the pmu
> once, then it's unnecessary (we zalloc vcpus). And, if we can
> recreate pmus with this call, then it'll create a memory leak, as
> we'll be zero-ing out all the perf_event pointers, and then won't
> be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
> we need to make sure we're NULL-ing them after each free instead.
>
Ok, will drop this.
>> + kvm_pmu_vcpu_reset(vcpu);
>> + pmu->irq_num = -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
>> +{
>> + kfree(dev);
>> +}
>> +
>> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg;
>> +
>> + if (get_user(reg, uaddr))
>> + return -EFAULT;
>> +
>> + /*
>> + * The PMU overflow interrupt could be a PPI or SPI, but for one
>> + * VM the interrupt type must be same for each vcpu. As a PPI,
>> + * the interrupt number is same for all vcpus, while as a SPI it
>> + * must be different for each vcpu.
>> + */
>> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
>> + return -EINVAL;
>> +
>> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + int ret;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
>> + int __user *uaddr = (int __user *)(long)attr->addr;
>> + int reg = -1;
>> +
>> +
>> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
>> + if (ret)
>> + return ret;
>> + return put_user(reg, uaddr);
>> + }
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
>> + struct kvm_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case KVM_DEV_ARM_PMU_GRP_IRQ:
>> + return 0;
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +struct kvm_device_ops kvm_arm_pmu_ops = {
>> + .name = "kvm-arm-pmu",
>> + .create = kvm_arm_pmu_create,
>> + .destroy = kvm_arm_pmu_destroy,
>> + .set_attr = kvm_arm_pmu_set_attr,
>> + .get_attr = kvm_arm_pmu_get_attr,
>> + .has_attr = kvm_arm_pmu_has_attr,
>> +};
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 484079e..81a42cc 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
>> #ifdef CONFIG_KVM_XICS
>> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
>> #endif
>> +
>> +#ifdef CONFIG_KVM_ARM_PMU
>> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
>
> Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
> device type name?
>
Sure, will add.
>> +#endif
>> };
>>
>> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>> --
>> 2.0.4
>>
>
> Thanks,
> drew
>
> .
>
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 14:56 ` Peter Maydell
@ 2016-01-08 3:06 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 3:06 UTC (permalink / raw)
To: Peter Maydell
Cc: arm-mail-list, kvm-devel, Marc Zyngier, Will Deacon,
Shannon Zhao, kvmarm
On 2016/1/7 22:56, Peter Maydell wrote:
>>>> + Errors:
>>>> >>> + -ENXIO: Unsupported attribute group
>>>> >>> + -EBUSY: The PMU overflow interrupt is already set
>>>> >>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>> >>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>> >>
>>> >> What happens if you create a PMU but then never set the IRQ number?
>>> >> Is there a default or does the VM refuse to run or something?
>>> >>
>> > If userspace doesn't specify the irq number, the guest will not receive
>> > the PMU interrupt because we check if the irq is initialized when we
>> > inject the interrupt. But guest could still use the vPMU if QEMU
>> > generates a proper DTB or ACPI.
> So is it a valid use case to create a PMU with the interrupt not wired
> up to anything? (If it's never valid it would be nice to diagnose it
> rather than just silently letting the guest run but not work right.)
So how about adding a helper to check if the PMU is completely
initialized and if not, return trap_raz_wi when guest access PMU registers?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 3:06 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 3:06 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/7 22:56, Peter Maydell wrote:
>>>> + Errors:
>>>> >>> + -ENXIO: Unsupported attribute group
>>>> >>> + -EBUSY: The PMU overflow interrupt is already set
>>>> >>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>> >>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>> >>
>>> >> What happens if you create a PMU but then never set the IRQ number?
>>> >> Is there a default or does the VM refuse to run or something?
>>> >>
>> > If userspace doesn't specify the irq number, the guest will not receive
>> > the PMU interrupt because we check if the irq is initialized when we
>> > inject the interrupt. But guest could still use the vPMU if QEMU
>> > generates a proper DTB or ACPI.
> So is it a valid use case to create a PMU with the interrupt not wired
> up to anything? (If it's never valid it would be nice to diagnose it
> rather than just silently letting the guest run but not work right.)
So how about adding a helper to check if the PMU is completely
initialized and if not, return trap_raz_wi when guest access PMU registers?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 3:06 ` Shannon Zhao
@ 2016-01-08 10:24 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-08 10:24 UTC (permalink / raw)
To: Shannon Zhao
Cc: arm-mail-list, kvm-devel, Marc Zyngier, Will Deacon,
Shannon Zhao, kvmarm
On 8 January 2016 at 03:06, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 22:56, Peter Maydell wrote:
>>>>> + Errors:
>>>>> >>> + -ENXIO: Unsupported attribute group
>>>>> >>> + -EBUSY: The PMU overflow interrupt is already set
>>>>> >>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>>> >>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>>> >>
>>>> >> What happens if you create a PMU but then never set the IRQ number?
>>>> >> Is there a default or does the VM refuse to run or something?
>>>> >>
>>> > If userspace doesn't specify the irq number, the guest will not receive
>>> > the PMU interrupt because we check if the irq is initialized when we
>>> > inject the interrupt. But guest could still use the vPMU if QEMU
>>> > generates a proper DTB or ACPI.
>> So is it a valid use case to create a PMU with the interrupt not wired
>> up to anything? (If it's never valid it would be nice to diagnose it
>> rather than just silently letting the guest run but not work right.)
> So how about adding a helper to check if the PMU is completely
> initialized and if not, return trap_raz_wi when guest access PMU registers?
That would still be letting the guest run and not work right.
If we have an "I have now completed config" ioctl like the GIC does,
then you could make that ioctl return an error if the config is not
valid.
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 10:24 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-08 10:24 UTC (permalink / raw)
To: linux-arm-kernel
On 8 January 2016 at 03:06, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2016/1/7 22:56, Peter Maydell wrote:
>>>>> + Errors:
>>>>> >>> + -ENXIO: Unsupported attribute group
>>>>> >>> + -EBUSY: The PMU overflow interrupt is already set
>>>>> >>> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>>> >>> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>>> >>
>>>> >> What happens if you create a PMU but then never set the IRQ number?
>>>> >> Is there a default or does the VM refuse to run or something?
>>>> >>
>>> > If userspace doesn't specify the irq number, the guest will not receive
>>> > the PMU interrupt because we check if the irq is initialized when we
>>> > inject the interrupt. But guest could still use the vPMU if QEMU
>>> > generates a proper DTB or ACPI.
>> So is it a valid use case to create a PMU with the interrupt not wired
>> up to anything? (If it's never valid it would be nice to diagnose it
>> rather than just silently letting the guest run but not work right.)
> So how about adding a helper to check if the PMU is completely
> initialized and if not, return trap_raz_wi when guest access PMU registers?
That would still be letting the guest run and not work right.
If we have an "I have now completed config" ioctl like the GIC does,
then you could make that ioctl return an error if the config is not
valid.
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 2:53 ` Shannon Zhao
@ 2016-01-08 11:22 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 11:22 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Fri, Jan 08, 2016 at 10:53:03AM +0800, Shannon Zhao wrote:
>
>
> On 2016/1/8 4:18, Andrew Jones wrote:
> > On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
> >> From: Shannon Zhao <shannon.zhao@linaro.org>
> >>
> >> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> >> the kvm_device_ops for it.
> >>
> >> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >> ---
> >> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> >> arch/arm64/include/uapi/asm/kvm.h | 4 +
> >> include/linux/kvm_host.h | 1 +
> >> include/uapi/linux/kvm.h | 2 +
> >> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> >> virt/kvm/kvm_main.c | 4 +
> >> 6 files changed, 163 insertions(+)
> >> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
> >>
> >> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> >> new file mode 100644
> >> index 0000000..dda864e
> >> --- /dev/null
> >> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> >> @@ -0,0 +1,24 @@
> >> +ARM Virtual Performance Monitor Unit (vPMU)
> >> +===========================================
> >> +
> >> +Device types supported:
> >> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> >> +
> >> +Instantiate one PMU instance for per VCPU through this API.
> > ^^ don't need this 'for' here
> >
> >> +
> >> +Groups:
> >> + KVM_DEV_ARM_PMU_GRP_IRQ
> >> + Attributes:
> >> + The attr field of kvm_device_attr encodes one value:
> >> + bits: | 63 .... 32 | 31 .... 0 |
> >> + values: | reserved | vcpu_index |
> >
> > Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
> > saying that that's good, but expanding it to 32 bits here is
> > inconsistent.
> Expand it to 32 bits just in case it needs to support more than 256
> vcpus in the future. If you think this is not good, I'll change it to 8
> bits.
I agree that eventually we'll want more than 256 vcpus. However the kvm
api already has the concept of a vcpu-index, which shows up in two other
places, KVM_IRQ_LINE and KVM_DEV_ARM_VGIC_*. In both those other places
it's only 8 bits. While there may not be a KVM_VCPU_INDEX_MASK=0xff
somewhere, I still think we should keep things consistent.
Hmm, or each device should define its own index. Actually, that sounds
better, as each device may have a different max-vcpus limit; KVM_IRQ_LINE
has 8 bits due to the x86 apic supporting 8 bits, gicv2 could have gotten
by with only 3 bits, and gicv3 can use much, much more. When we want more
than 256 vcpus we'll need a new kvm-irq-line ioctl, but, as for the arm
devices, we could avoid the problem completely by extending the
SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
>
> (A side note is that I think we should s/vcpu_index/vcpu_id/
> > in order to keep the parameter name consistent with what's used by
> > KVM_CREATE_VCPU)
> >
> Eh, I make it consistent with vGIC which is a kvm device that's also
> created via KVM_CREATE_DEVICE API. So they are different names but
> express same thing.
I knew you are consistent with arm-vgic.txt, and also with KVM_IRQ_LINE.
I was just thinking that it'd be nice for everything to be consistent
with KVM_CREATE_VCPU. However, now I'm of the mind that the vcpu-id
(32 bits) should always be independent of device vcpu-indexes, as we
don't want to limit the number of vcpus (by limiting vcpu-ids) to the
maximum of the most-limited device we support.
>
> >> + A value describing the PMU overflow interrupt number for the specified
> >> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >> +
> >> + Errors:
> >> + -ENXIO: Unsupported attribute group
> >
> > Do we need to specify ENXIO here? It's already specified in
> > Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
> >
> But specifying it here is not bad, right? If you insist on this, I'll
> drop it.
It's fine, as the specification in SET/GET_DEVICE_ATTR section isn't
going to change, but we require users of this api to read that section
already, so I feel it's redundant and prefer to avoid redundancy. I won't
insist.
>
> >> + -EBUSY: The PMU overflow interrupt is already set
> >> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> >> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> index 2d4ca4b..cbb9022 100644
> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
> >>
> >> +/* Device Control API: ARM PMU */
> >> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> >> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
> >
> > I don't think we should need a mask like this, at least not in the uapi.
> > The documentation says to use a vcpu-index [really a vcpu-id], and users
> > should know how to convert their vcpu handle (whatever that may be) to
> > a vcpu-id using whatever transformation is necessary. They may already
> > have a "vcpu id mask" defined (this is one reason why I don't think we
> > should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
> > everywhere else). Likewise, kvm should know how to do it's transformation.
> > Maybe, to aid in the attr field construction, we should supply a shift,
> > allowing both sides to do something like
> >
> > int pmu_attr_extract_vcpu_id(u64 attr)
> > {
> > return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
> So what's the value of the VCPU_ID_MASK? I didn't see any definitions
> about it. It looks like KVM_DEV_ARM_PMU_CPUID_MASK(just has a difference
> between 32 bits and 8 bits)
Whether or not a user would define a VCPU_ID_MASK == 0xff depends on
whether or not they understand 'vcpu-index' to be a consistent concept
everywhere they see it in the documentation. I now would prefer
vcpu-index being device specific. Going that way, then I think the
documentation could be updated to help make that clearer, e.g. calling
the gic vcpu-index gic_vcpu_index or something.
>
> > }
> >
> > u64 pmu_attr_create(int vcpu_id)
> > {
> > return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
> > }
> >
> > But, in this case the shift is zero, so it's not really necessary. In
> > any case, please add the 'V' for VCPU.
> >
> >> +
> >> /* KVM_IRQ_LINE irq field index values */
> >> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> >> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> index c923350..608dea6 100644
> >> --- a/include/linux/kvm_host.h
> >> +++ b/include/linux/kvm_host.h
> >> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> >> extern struct kvm_device_ops kvm_xics_ops;
> >> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> >> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> >> +extern struct kvm_device_ops kvm_arm_pmu_ops;
> >>
> >> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
> >>
> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >> index 03f3618..4ba6fdd 100644
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> >> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> >> KVM_DEV_TYPE_ARM_VGIC_V3,
> >> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> >> + KVM_DEV_TYPE_ARM_PMU_V3,
> >> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> >> KVM_DEV_TYPE_MAX,
> >> };
> >>
> >> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> >> index 3ec3cdd..5518308 100644
> >> --- a/virt/kvm/arm/pmu.c
> >> +++ b/virt/kvm/arm/pmu.c
> >> @@ -19,6 +19,7 @@
> >> #include <linux/kvm.h>
> >> #include <linux/kvm_host.h>
> >> #include <linux/perf_event.h>
> >> +#include <linux/uaccess.h>
> >> #include <asm/kvm_emulate.h>
> >> #include <kvm/arm_pmu.h>
> >> #include <kvm/arm_vgic.h>
> >> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> >>
> >> pmc->perf_event = event;
> >> }
> >> +
> >> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> >> +{
> >> + return vcpu->arch.pmu.irq_num != -1;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> >> + int *irq, bool is_set)
> >> +{
> >> + int cpuid;
> >
> > please call this vcpu_id
> >
> >> + struct kvm_vcpu *vcpu;
> >> + struct kvm_pmu *pmu;
> >> +
> >> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> >> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> >> + return -EINVAL;
> >> +
> >> + vcpu = kvm_get_vcpu(kvm, cpuid);
> >> + if (!vcpu)
> >> + return -EINVAL;
> >> +
> >> + pmu = &vcpu->arch.pmu;
> >> + if (!is_set) {
> >> + if (!kvm_arm_pmu_initialized(vcpu))
> >> + return -ENODEV;
> >> +
> >> + *irq = pmu->irq_num;
> >> + } else {
> >> + if (kvm_arm_pmu_initialized(vcpu))
> >> + return -EBUSY;
> >> +
> >> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> >> + pmu->irq_num = *irq;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> >> +{
> >> + int i;
> >> + struct kvm_vcpu *vcpu;
> >> + struct kvm *kvm = dev->kvm;
> >> +
> >> + kvm_for_each_vcpu(i, vcpu, kvm) {
> >> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> >> +
> >> + memset(pmu, 0, sizeof(*pmu));
> >
> > I don't think we want this memset. If we can only create the pmu
> > once, then it's unnecessary (we zalloc vcpus). And, if we can
> > recreate pmus with this call, then it'll create a memory leak, as
> > we'll be zero-ing out all the perf_event pointers, and then won't
> > be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
> > we need to make sure we're NULL-ing them after each free instead.
> >
> Ok, will drop this.
>
> >> + kvm_pmu_vcpu_reset(vcpu);
> >> + pmu->irq_num = -1;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> >> +{
> >> + kfree(dev);
> >> +}
> >> +
> >> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> >> + int __user *uaddr = (int __user *)(long)attr->addr;
> >> + int reg;
> >> +
> >> + if (get_user(reg, uaddr))
> >> + return -EFAULT;
> >> +
> >> + /*
> >> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> >> + * VM the interrupt type must be same for each vcpu. As a PPI,
> >> + * the interrupt number is same for all vcpus, while as a SPI it
> >> + * must be different for each vcpu.
> >> + */
> >> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> >> + return -EINVAL;
> >> +
> >> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> >> + }
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + int ret;
> >> +
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> >> + int __user *uaddr = (int __user *)(long)attr->addr;
> >> + int reg = -1;
> >> +
> >> +
> >> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> >> + if (ret)
> >> + return ret;
> >> + return put_user(reg, uaddr);
> >> + }
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> >> + return 0;
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +struct kvm_device_ops kvm_arm_pmu_ops = {
> >> + .name = "kvm-arm-pmu",
> >> + .create = kvm_arm_pmu_create,
> >> + .destroy = kvm_arm_pmu_destroy,
> >> + .set_attr = kvm_arm_pmu_set_attr,
> >> + .get_attr = kvm_arm_pmu_get_attr,
> >> + .has_attr = kvm_arm_pmu_has_attr,
> >> +};
> >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >> index 484079e..81a42cc 100644
> >> --- a/virt/kvm/kvm_main.c
> >> +++ b/virt/kvm/kvm_main.c
> >> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> >> #ifdef CONFIG_KVM_XICS
> >> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> >> #endif
> >> +
> >> +#ifdef CONFIG_KVM_ARM_PMU
> >> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
> >
> > Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
> > device type name?
> >
> Sure, will add.
>
> >> +#endif
> >> };
> >>
> >> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
> >> --
> >> 2.0.4
> >>
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 11:22 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 10:53:03AM +0800, Shannon Zhao wrote:
>
>
> On 2016/1/8 4:18, Andrew Jones wrote:
> > On Tue, Dec 22, 2015 at 04:08:15PM +0800, Shannon Zhao wrote:
> >> From: Shannon Zhao <shannon.zhao@linaro.org>
> >>
> >> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> >> the kvm_device_ops for it.
> >>
> >> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >> ---
> >> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +++++
> >> arch/arm64/include/uapi/asm/kvm.h | 4 +
> >> include/linux/kvm_host.h | 1 +
> >> include/uapi/linux/kvm.h | 2 +
> >> virt/kvm/arm/pmu.c | 128 ++++++++++++++++++++++++++
> >> virt/kvm/kvm_main.c | 4 +
> >> 6 files changed, 163 insertions(+)
> >> create mode 100644 Documentation/virtual/kvm/devices/arm-pmu.txt
> >>
> >> diff --git a/Documentation/virtual/kvm/devices/arm-pmu.txt b/Documentation/virtual/kvm/devices/arm-pmu.txt
> >> new file mode 100644
> >> index 0000000..dda864e
> >> --- /dev/null
> >> +++ b/Documentation/virtual/kvm/devices/arm-pmu.txt
> >> @@ -0,0 +1,24 @@
> >> +ARM Virtual Performance Monitor Unit (vPMU)
> >> +===========================================
> >> +
> >> +Device types supported:
> >> + KVM_DEV_TYPE_ARM_PMU_V3 ARM Performance Monitor Unit v3
> >> +
> >> +Instantiate one PMU instance for per VCPU through this API.
> > ^^ don't need this 'for' here
> >
> >> +
> >> +Groups:
> >> + KVM_DEV_ARM_PMU_GRP_IRQ
> >> + Attributes:
> >> + The attr field of kvm_device_attr encodes one value:
> >> + bits: | 63 .... 32 | 31 .... 0 |
> >> + values: | reserved | vcpu_index |
> >
> > Everywhere else in kvm documentation a vcpu_index is 8 bits. I'm not
> > saying that that's good, but expanding it to 32 bits here is
> > inconsistent.
> Expand it to 32 bits just in case it needs to support more than 256
> vcpus in the future. If you think this is not good, I'll change it to 8
> bits.
I agree that eventually we'll want more than 256 vcpus. However the kvm
api already has the concept of a vcpu-index, which shows up in two other
places, KVM_IRQ_LINE and KVM_DEV_ARM_VGIC_*. In both those other places
it's only 8 bits. While there may not be a KVM_VCPU_INDEX_MASK=0xff
somewhere, I still think we should keep things consistent.
Hmm, or each device should define its own index. Actually, that sounds
better, as each device may have a different max-vcpus limit; KVM_IRQ_LINE
has 8 bits due to the x86 apic supporting 8 bits, gicv2 could have gotten
by with only 3 bits, and gicv3 can use much, much more. When we want more
than 256 vcpus we'll need a new kvm-irq-line ioctl, but, as for the arm
devices, we could avoid the problem completely by extending the
SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
>
> (A side note is that I think we should s/vcpu_index/vcpu_id/
> > in order to keep the parameter name consistent with what's used by
> > KVM_CREATE_VCPU)
> >
> Eh, I make it consistent with vGIC which is a kvm device that's also
> created via KVM_CREATE_DEVICE API. So they are different names but
> express same thing.
I knew you are consistent with arm-vgic.txt, and also with KVM_IRQ_LINE.
I was just thinking that it'd be nice for everything to be consistent
with KVM_CREATE_VCPU. However, now I'm of the mind that the vcpu-id
(32 bits) should always be independent of device vcpu-indexes, as we
don't want to limit the number of vcpus (by limiting vcpu-ids) to the
maximum of the most-limited device we support.
>
> >> + A value describing the PMU overflow interrupt number for the specified
> >> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >> +
> >> + Errors:
> >> + -ENXIO: Unsupported attribute group
> >
> > Do we need to specify ENXIO here? It's already specified in
> > Documentation/virtual/kvm/api.txt for SET/GET_DEVICE_ATTR
> >
> But specifying it here is not bad, right? If you insist on this, I'll
> drop it.
It's fine, as the specification in SET/GET_DEVICE_ATTR section isn't
going to change, but we require users of this api to read that section
already, so I feel it's redundant and prefer to avoid redundancy. I won't
insist.
>
> >> + -EBUSY: The PMU overflow interrupt is already set
> >> + -ENODEV: Getting the PMU overflow interrupt number while it's not set
> >> + -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> index 2d4ca4b..cbb9022 100644
> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> @@ -204,6 +204,10 @@ struct kvm_arch_memory_slot {
> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
> >>
> >> +/* Device Control API: ARM PMU */
> >> +#define KVM_DEV_ARM_PMU_GRP_IRQ 0
> >> +#define KVM_DEV_ARM_PMU_CPUID_MASK 0xffffffffULL
> >
> > I don't think we should need a mask like this, at least not in the uapi.
> > The documentation says to use a vcpu-index [really a vcpu-id], and users
> > should know how to convert their vcpu handle (whatever that may be) to
> > a vcpu-id using whatever transformation is necessary. They may already
> > have a "vcpu id mask" defined (this is one reason why I don't think we
> > should use a 32-bit vcpu-index here, instead of the 8-bit vcpu-index used
> > everywhere else). Likewise, kvm should know how to do it's transformation.
> > Maybe, to aid in the attr field construction, we should supply a shift,
> > allowing both sides to do something like
> >
> > int pmu_attr_extract_vcpu_id(u64 attr)
> > {
> > return (attr >> KVM_DEV_ARM_PMU_VCPUID_SHIFT) & VCPU_ID_MASK;
> So what's the value of the VCPU_ID_MASK? I didn't see any definitions
> about it. It looks like KVM_DEV_ARM_PMU_CPUID_MASK(just has a difference
> between 32 bits and 8 bits)
Whether or not a user would define a VCPU_ID_MASK == 0xff depends on
whether or not they understand 'vcpu-index' to be a consistent concept
everywhere they see it in the documentation. I now would prefer
vcpu-index being device specific. Going that way, then I think the
documentation could be updated to help make that clearer, e.g. calling
the gic vcpu-index gic_vcpu_index or something.
>
> > }
> >
> > u64 pmu_attr_create(int vcpu_id)
> > {
> > return vcpu_id << KVM_DEV_ARM_PMU_VCPUID_SHIFT;
> > }
> >
> > But, in this case the shift is zero, so it's not really necessary. In
> > any case, please add the 'V' for VCPU.
> >
> >> +
> >> /* KVM_IRQ_LINE irq field index values */
> >> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> >> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> index c923350..608dea6 100644
> >> --- a/include/linux/kvm_host.h
> >> +++ b/include/linux/kvm_host.h
> >> @@ -1161,6 +1161,7 @@ extern struct kvm_device_ops kvm_mpic_ops;
> >> extern struct kvm_device_ops kvm_xics_ops;
> >> extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
> >> extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
> >> +extern struct kvm_device_ops kvm_arm_pmu_ops;
> >>
> >> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
> >>
> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >> index 03f3618..4ba6fdd 100644
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@ -1032,6 +1032,8 @@ enum kvm_device_type {
> >> #define KVM_DEV_TYPE_FLIC KVM_DEV_TYPE_FLIC
> >> KVM_DEV_TYPE_ARM_VGIC_V3,
> >> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> >> + KVM_DEV_TYPE_ARM_PMU_V3,
> >> +#define KVM_DEV_TYPE_ARM_PMU_V3 KVM_DEV_TYPE_ARM_PMU_V3
> >> KVM_DEV_TYPE_MAX,
> >> };
> >>
> >> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> >> index 3ec3cdd..5518308 100644
> >> --- a/virt/kvm/arm/pmu.c
> >> +++ b/virt/kvm/arm/pmu.c
> >> @@ -19,6 +19,7 @@
> >> #include <linux/kvm.h>
> >> #include <linux/kvm_host.h>
> >> #include <linux/perf_event.h>
> >> +#include <linux/uaccess.h>
> >> #include <asm/kvm_emulate.h>
> >> #include <kvm/arm_pmu.h>
> >> #include <kvm/arm_vgic.h>
> >> @@ -374,3 +375,130 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> >>
> >> pmc->perf_event = event;
> >> }
> >> +
> >> +static inline bool kvm_arm_pmu_initialized(struct kvm_vcpu *vcpu)
> >> +{
> >> + return vcpu->arch.pmu.irq_num != -1;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_irq_access(struct kvm *kvm, struct kvm_device_attr *attr,
> >> + int *irq, bool is_set)
> >> +{
> >> + int cpuid;
> >
> > please call this vcpu_id
> >
> >> + struct kvm_vcpu *vcpu;
> >> + struct kvm_pmu *pmu;
> >> +
> >> + cpuid = attr->attr & KVM_DEV_ARM_PMU_CPUID_MASK;
> >> + if (cpuid >= atomic_read(&kvm->online_vcpus))
> >> + return -EINVAL;
> >> +
> >> + vcpu = kvm_get_vcpu(kvm, cpuid);
> >> + if (!vcpu)
> >> + return -EINVAL;
> >> +
> >> + pmu = &vcpu->arch.pmu;
> >> + if (!is_set) {
> >> + if (!kvm_arm_pmu_initialized(vcpu))
> >> + return -ENODEV;
> >> +
> >> + *irq = pmu->irq_num;
> >> + } else {
> >> + if (kvm_arm_pmu_initialized(vcpu))
> >> + return -EBUSY;
> >> +
> >> + kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> >> + pmu->irq_num = *irq;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_create(struct kvm_device *dev, u32 type)
> >> +{
> >> + int i;
> >> + struct kvm_vcpu *vcpu;
> >> + struct kvm *kvm = dev->kvm;
> >> +
> >> + kvm_for_each_vcpu(i, vcpu, kvm) {
> >> + struct kvm_pmu *pmu = &vcpu->arch.pmu;
> >> +
> >> + memset(pmu, 0, sizeof(*pmu));
> >
> > I don't think we want this memset. If we can only create the pmu
> > once, then it's unnecessary (we zalloc vcpus). And, if we can
> > recreate pmus with this call, then it'll create a memory leak, as
> > we'll be zero-ing out all the perf_event pointers, and then won't
> > be able to free them on the call to kvm_pmu_vcpu_reset. Naturally
> > we need to make sure we're NULL-ing them after each free instead.
> >
> Ok, will drop this.
>
> >> + kvm_pmu_vcpu_reset(vcpu);
> >> + pmu->irq_num = -1;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static void kvm_arm_pmu_destroy(struct kvm_device *dev)
> >> +{
> >> + kfree(dev);
> >> +}
> >> +
> >> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> >> + int __user *uaddr = (int __user *)(long)attr->addr;
> >> + int reg;
> >> +
> >> + if (get_user(reg, uaddr))
> >> + return -EFAULT;
> >> +
> >> + /*
> >> + * The PMU overflow interrupt could be a PPI or SPI, but for one
> >> + * VM the interrupt type must be same for each vcpu. As a PPI,
> >> + * the interrupt number is same for all vcpus, while as a SPI it
> >> + * must be different for each vcpu.
> >> + */
> >> + if (reg < VGIC_NR_SGIS || reg >= dev->kvm->arch.vgic.nr_irqs)
> >> + return -EINVAL;
> >> +
> >> + return kvm_arm_pmu_irq_access(dev->kvm, attr, ®, true);
> >> + }
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_get_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + int ret;
> >> +
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ: {
> >> + int __user *uaddr = (int __user *)(long)attr->addr;
> >> + int reg = -1;
> >> +
> >> +
> >> + ret = kvm_arm_pmu_irq_access(dev->kvm, attr, ®, false);
> >> + if (ret)
> >> + return ret;
> >> + return put_user(reg, uaddr);
> >> + }
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +static int kvm_arm_pmu_has_attr(struct kvm_device *dev,
> >> + struct kvm_device_attr *attr)
> >> +{
> >> + switch (attr->group) {
> >> + case KVM_DEV_ARM_PMU_GRP_IRQ:
> >> + return 0;
> >> + }
> >> +
> >> + return -ENXIO;
> >> +}
> >> +
> >> +struct kvm_device_ops kvm_arm_pmu_ops = {
> >> + .name = "kvm-arm-pmu",
> >> + .create = kvm_arm_pmu_create,
> >> + .destroy = kvm_arm_pmu_destroy,
> >> + .set_attr = kvm_arm_pmu_set_attr,
> >> + .get_attr = kvm_arm_pmu_get_attr,
> >> + .has_attr = kvm_arm_pmu_has_attr,
> >> +};
> >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >> index 484079e..81a42cc 100644
> >> --- a/virt/kvm/kvm_main.c
> >> +++ b/virt/kvm/kvm_main.c
> >> @@ -2647,6 +2647,10 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
> >> #ifdef CONFIG_KVM_XICS
> >> [KVM_DEV_TYPE_XICS] = &kvm_xics_ops,
> >> #endif
> >> +
> >> +#ifdef CONFIG_KVM_ARM_PMU
> >> + [KVM_DEV_TYPE_ARM_PMU_V3] = &kvm_arm_pmu_ops,
> >
> > Shouldn't we specify 'v3' in the kvm_arm_pmu_ops name, as we do with the
> > device type name?
> >
> Sure, will add.
>
> >> +#endif
> >> };
> >>
> >> int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
> >> --
> >> 2.0.4
> >>
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 10:24 ` Peter Maydell
@ 2016-01-08 12:15 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 12:15 UTC (permalink / raw)
To: Peter Maydell, Shannon Zhao
Cc: kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel, Will Deacon,
arm-mail-list
On 2016/1/8 18:24, Peter Maydell wrote:
> On 8 January 2016 at 03:06, Shannon Zhao<zhaoshenglong@huawei.com> wrote:
>> >
>> >
>> >On 2016/1/7 22:56, Peter Maydell wrote:
>>>>>> >>>>>+ Errors:
>>>>>>>>> >>>>> >>>+ -ENXIO: Unsupported attribute group
>>>>>>>>> >>>>> >>>+ -EBUSY: The PMU overflow interrupt is already set
>>>>>>>>> >>>>> >>>+ -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>>>>>>> >>>>> >>>+ -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>>>>>> >>>> >>
>>>>>>> >>>> >>What happens if you create a PMU but then never set the IRQ number?
>>>>>>> >>>> >>Is there a default or does the VM refuse to run or something?
>>>>>>> >>>> >>
>>>>> >>> >If userspace doesn't specify the irq number, the guest will not receive
>>>>> >>> >the PMU interrupt because we check if the irq is initialized when we
>>>>> >>> >inject the interrupt. But guest could still use the vPMU if QEMU
>>>>> >>> >generates a proper DTB or ACPI.
>>> >>So is it a valid use case to create a PMU with the interrupt not wired
>>> >>up to anything? (If it's never valid it would be nice to diagnose it
>>> >>rather than just silently letting the guest run but not work right.)
>> >So how about adding a helper to check if the PMU is completely
>> >initialized and if not, return trap_raz_wi when guest access PMU registers?
> That would still be letting the guest run and not work right.
>
> If we have an "I have now completed config" ioctl like the GIC does,
> then you could make that ioctl return an error if the config is not
> valid.
Firstly, userspace will call kvm device ioctl to create the PMU device,
if it fails it will return an error.
Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU
irq number. If the irq is invalid, this will return an error and the
userspace will stop if it takes care the error. If the irq is valid, the
PMU is well initialized.
If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the
PMU is not well initialized and guest can't use the PMU.
I didn't see anywhere that needs to call something like
KVM_DEV_ARM_VGIC_CTRL_INIT to let kvm initialize PMU because it will be
initialized when userspace configure the irq correctly. This is a little
different with the vGIC I think.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 12:15 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 12:15 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/8 18:24, Peter Maydell wrote:
> On 8 January 2016 at 03:06, Shannon Zhao<zhaoshenglong@huawei.com> wrote:
>> >
>> >
>> >On 2016/1/7 22:56, Peter Maydell wrote:
>>>>>> >>>>>+ Errors:
>>>>>>>>> >>>>> >>>+ -ENXIO: Unsupported attribute group
>>>>>>>>> >>>>> >>>+ -EBUSY: The PMU overflow interrupt is already set
>>>>>>>>> >>>>> >>>+ -ENODEV: Getting the PMU overflow interrupt number while it's not set
>>>>>>>>> >>>>> >>>+ -EINVAL: Invalid vcpu_index or PMU overflow interrupt number supplied
>>>>>>> >>>> >>
>>>>>>> >>>> >>What happens if you create a PMU but then never set the IRQ number?
>>>>>>> >>>> >>Is there a default or does the VM refuse to run or something?
>>>>>>> >>>> >>
>>>>> >>> >If userspace doesn't specify the irq number, the guest will not receive
>>>>> >>> >the PMU interrupt because we check if the irq is initialized when we
>>>>> >>> >inject the interrupt. But guest could still use the vPMU if QEMU
>>>>> >>> >generates a proper DTB or ACPI.
>>> >>So is it a valid use case to create a PMU with the interrupt not wired
>>> >>up to anything? (If it's never valid it would be nice to diagnose it
>>> >>rather than just silently letting the guest run but not work right.)
>> >So how about adding a helper to check if the PMU is completely
>> >initialized and if not, return trap_raz_wi when guest access PMU registers?
> That would still be letting the guest run and not work right.
>
> If we have an "I have now completed config" ioctl like the GIC does,
> then you could make that ioctl return an error if the config is not
> valid.
Firstly, userspace will call kvm device ioctl to create the PMU device,
if it fails it will return an error.
Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU
irq number. If the irq is invalid, this will return an error and the
userspace will stop if it takes care the error. If the irq is valid, the
PMU is well initialized.
If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the
PMU is not well initialized and guest can't use the PMU.
I didn't see anywhere that needs to call something like
KVM_DEV_ARM_VGIC_CTRL_INIT to let kvm initialize PMU because it will be
initialized when userspace configure the irq correctly. This is a little
different with the vGIC I think.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 12:15 ` Shannon Zhao
@ 2016-01-08 12:56 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-08 12:56 UTC (permalink / raw)
To: Shannon Zhao
Cc: Shannon Zhao, kvmarm, Marc Zyngier, Christoffer Dall, kvm-devel,
Will Deacon, arm-mail-list
On 8 January 2016 at 12:15, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> Firstly, userspace will call kvm device ioctl to create the PMU device, if
> it fails it will return an error.
> Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU irq
> number. If the irq is invalid, this will return an error and the userspace
> will stop if it takes care the error. If the irq is valid, the PMU is well
> initialized.
>
> If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the PMU
> is not well initialized and guest can't use the PMU.
Yes, this is my point. If you require userspace to do:
* create PMU device
* configure PMU device via SET_DEVICE_ATTR
* complete init of PMU device via a KVM_DEV_ARM_PMU_CTRL_INIT attr
then any bugs on the userspace side where it isn't configuring
correctly can be easily caught, and will turn into a "VM fails
to start with helpful error message", rather than "VM starts but
doesn't work in an obscure way".
This is particularly important for devices which have userspace
visible registers, because userspace will also want to be able
to read and write state of those registers before first vcpu run.
If there is no "init is complete" ioctl then the kernel code ends
up having to guess when init has completed for various entry points
where the guest does something else (register access, vcpu start, etc).
It might happen to not be so important for the PMU, but I think it
would be very useful if we have a pattern where every device that
is created via this API works in the same way (and it means that if
we end up extending the PMU in future we will already have the API
in place and don't need to worry about legacy userspace).
Speaking of userspace access to registers, what is the intended API
for migrating the PMU register state ?
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 12:56 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-08 12:56 UTC (permalink / raw)
To: linux-arm-kernel
On 8 January 2016 at 12:15, Shannon Zhao <shannon.zhao@linaro.org> wrote:
> Firstly, userspace will call kvm device ioctl to create the PMU device, if
> it fails it will return an error.
> Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU irq
> number. If the irq is invalid, this will return an error and the userspace
> will stop if it takes care the error. If the irq is valid, the PMU is well
> initialized.
>
> If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the PMU
> is not well initialized and guest can't use the PMU.
Yes, this is my point. If you require userspace to do:
* create PMU device
* configure PMU device via SET_DEVICE_ATTR
* complete init of PMU device via a KVM_DEV_ARM_PMU_CTRL_INIT attr
then any bugs on the userspace side where it isn't configuring
correctly can be easily caught, and will turn into a "VM fails
to start with helpful error message", rather than "VM starts but
doesn't work in an obscure way".
This is particularly important for devices which have userspace
visible registers, because userspace will also want to be able
to read and write state of those registers before first vcpu run.
If there is no "init is complete" ioctl then the kernel code ends
up having to guess when init has completed for various entry points
where the guest does something else (register access, vcpu start, etc).
It might happen to not be so important for the PMU, but I think it
would be very useful if we have a pattern where every device that
is created via this API works in the same way (and it means that if
we end up extending the PMU in future we will already have the API
in place and don't need to worry about legacy userspace).
Speaking of userspace access to registers, what is the intended API
for migrating the PMU register state ?
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 12:56 ` Peter Maydell
@ 2016-01-08 13:31 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 13:31 UTC (permalink / raw)
To: Peter Maydell; +Cc: kvm-devel, Marc Zyngier, Will Deacon, arm-mail-list, kvmarm
On 2016/1/8 20:56, Peter Maydell wrote:
> On 8 January 2016 at 12:15, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> Firstly, userspace will call kvm device ioctl to create the PMU device, if
>> it fails it will return an error.
>> Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU irq
>> number. If the irq is invalid, this will return an error and the userspace
>> will stop if it takes care the error. If the irq is valid, the PMU is well
>> initialized.
>>
>> If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the PMU
>> is not well initialized and guest can't use the PMU.
>
> Yes, this is my point. If you require userspace to do:
> * create PMU device
> * configure PMU device via SET_DEVICE_ATTR
> * complete init of PMU device via a KVM_DEV_ARM_PMU_CTRL_INIT attr
>
> then any bugs on the userspace side where it isn't configuring
> correctly can be easily caught, and will turn into a "VM fails
> to start with helpful error message", rather than "VM starts but
> doesn't work in an obscure way".
>
> This is particularly important for devices which have userspace
> visible registers, because userspace will also want to be able
> to read and write state of those registers before first vcpu run.
> If there is no "init is complete" ioctl then the kernel code ends
> up having to guess when init has completed for various entry points
> where the guest does something else (register access, vcpu start, etc).
>
> It might happen to not be so important for the PMU, but I think it
> would be very useful if we have a pattern where every device that
> is created via this API works in the same way (and it means that if
> we end up extending the PMU in future we will already have the API
> in place and don't need to worry about legacy userspace).
>
> Speaking of userspace access to registers, what is the intended API
> for migrating the PMU register state ?
>
Since the PMU register states are stored in sys_regs[NR_SYS_REGS], they
could be migrated with other sys registers. There is only the "struct
perf_event *perf_event" we should take care of I think. I didn't figure
out a good way for this especially when guest is using the perf.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 13:31 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-08 13:31 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/8 20:56, Peter Maydell wrote:
> On 8 January 2016 at 12:15, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>> Firstly, userspace will call kvm device ioctl to create the PMU device, if
>> it fails it will return an error.
>> Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU irq
>> number. If the irq is invalid, this will return an error and the userspace
>> will stop if it takes care the error. If the irq is valid, the PMU is well
>> initialized.
>>
>> If userspace doesn't call SET_ATTR ioctl to configure the PMU irq, the PMU
>> is not well initialized and guest can't use the PMU.
>
> Yes, this is my point. If you require userspace to do:
> * create PMU device
> * configure PMU device via SET_DEVICE_ATTR
> * complete init of PMU device via a KVM_DEV_ARM_PMU_CTRL_INIT attr
>
> then any bugs on the userspace side where it isn't configuring
> correctly can be easily caught, and will turn into a "VM fails
> to start with helpful error message", rather than "VM starts but
> doesn't work in an obscure way".
>
> This is particularly important for devices which have userspace
> visible registers, because userspace will also want to be able
> to read and write state of those registers before first vcpu run.
> If there is no "init is complete" ioctl then the kernel code ends
> up having to guess when init has completed for various entry points
> where the guest does something else (register access, vcpu start, etc).
>
> It might happen to not be so important for the PMU, but I think it
> would be very useful if we have a pattern where every device that
> is created via this API works in the same way (and it means that if
> we end up extending the PMU in future we will already have the API
> in place and don't need to worry about legacy userspace).
>
> Speaking of userspace access to registers, what is the intended API
> for migrating the PMU register state ?
>
Since the PMU register states are stored in sys_regs[NR_SYS_REGS], they
could be migrated with other sys registers. There is only the "struct
perf_event *perf_event" we should take care of I think. I didn't figure
out a good way for this especially when guest is using the perf.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 11:22 ` Andrew Jones
@ 2016-01-08 15:20 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 15:20 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvm, marc.zyngier, shannon.zhao, will.deacon, linux-arm-kernel, kvmarm
On Fri, Jan 08, 2016 at 12:22:13PM +0100, Andrew Jones wrote:
> When we want more than 256 vcpus we'll need a new kvm-irq-line ioctl,
> but, as for the arm devices, we could avoid the problem completely by
> extending the SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
Replying to myself on this comment. The arm-gic device is fine as is, as
it really is a vm device. However I'm convincing myself more and more
(and with the help of Radim Krcmar being my sounding board) that using
the device api for the pmu is wrong (at least as a per-vm device). The
pmu is a per-vcpu device.
I think we should consider adding KVM_CREATE_DEVICE, KVM_SET/GET_DEVICE_ATTR
to the vcpu ioctl to allow per-vcpu devices. Then, instead of looping vcpus
in the kernel to init the pmu per vcpu on the call to KVM_CREATE_DEVICE,
we'd have the more natural looping in userspace. Also, the set-attr for the
irq would be part of that loop, and no longer need a vcpu-index parameter.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 15:20 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 15:20 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 12:22:13PM +0100, Andrew Jones wrote:
> When we want more than 256 vcpus we'll need a new kvm-irq-line ioctl,
> but, as for the arm devices, we could avoid the problem completely by
> extending the SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
Replying to myself on this comment. The arm-gic device is fine as is, as
it really is a vm device. However I'm convincing myself more and more
(and with the help of Radim Krcmar being my sounding board) that using
the device api for the pmu is wrong (at least as a per-vm device). The
pmu is a per-vcpu device.
I think we should consider adding KVM_CREATE_DEVICE, KVM_SET/GET_DEVICE_ATTR
to the vcpu ioctl to allow per-vcpu devices. Then, instead of looping vcpus
in the kernel to init the pmu per vcpu on the call to KVM_CREATE_DEVICE,
we'd have the more natural looping in userspace. Also, the set-attr for the
irq would be part of that loop, and no longer need a vcpu-index parameter.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-08 15:20 ` Andrew Jones
@ 2016-01-08 15:59 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 15:59 UTC (permalink / raw)
To: Shannon Zhao
Cc: kvmarm, marc.zyngier, christoffer.dall, linux-arm-kernel, kvm,
will.deacon, wei, cov, shannon.zhao, peter.huangpeng, hangaohuai
On Fri, Jan 08, 2016 at 04:20:28PM +0100, Andrew Jones wrote:
> On Fri, Jan 08, 2016 at 12:22:13PM +0100, Andrew Jones wrote:
> > When we want more than 256 vcpus we'll need a new kvm-irq-line ioctl,
> > but, as for the arm devices, we could avoid the problem completely by
> > extending the SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
>
> Replying to myself on this comment. The arm-gic device is fine as is, as
> it really is a vm device. However I'm convincing myself more and more
> (and with the help of Radim Krcmar being my sounding board) that using
> the device api for the pmu is wrong (at least as a per-vm device). The
> pmu is a per-vcpu device.
>
> I think we should consider adding KVM_CREATE_DEVICE, KVM_SET/GET_DEVICE_ATTR
> to the vcpu ioctl to allow per-vcpu devices. Then, instead of looping vcpus
> in the kernel to init the pmu per vcpu on the call to KVM_CREATE_DEVICE,
> we'd have the more natural looping in userspace. Also, the set-attr for the
> irq would be part of that loop, and no longer need a vcpu-index parameter.
>
Another note, for this pmu device we don't actually need KVM_CREATE_DEVICE
to be a vcpu ioctl. We can just add another vcpu-init feature flag that we
set with KVM_ARM_VCPU_INIT in order to "create" the pmu. We still need to
add KVM_SET/GET_DEVICE_ATTR to the vcpu ioctl though, allowing the irq to
be set. KVM_ARM_PMU_GRP_IRQ will just become a vcpu attribute.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-08 15:59 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-08 15:59 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 04:20:28PM +0100, Andrew Jones wrote:
> On Fri, Jan 08, 2016 at 12:22:13PM +0100, Andrew Jones wrote:
> > When we want more than 256 vcpus we'll need a new kvm-irq-line ioctl,
> > but, as for the arm devices, we could avoid the problem completely by
> > extending the SET/GET_DEVICE_ATTR ioctl to also be a vcpu ioctl.
>
> Replying to myself on this comment. The arm-gic device is fine as is, as
> it really is a vm device. However I'm convincing myself more and more
> (and with the help of Radim Krcmar being my sounding board) that using
> the device api for the pmu is wrong (at least as a per-vm device). The
> pmu is a per-vcpu device.
>
> I think we should consider adding KVM_CREATE_DEVICE, KVM_SET/GET_DEVICE_ATTR
> to the vcpu ioctl to allow per-vcpu devices. Then, instead of looping vcpus
> in the kernel to init the pmu per vcpu on the call to KVM_CREATE_DEVICE,
> we'd have the more natural looping in userspace. Also, the set-attr for the
> irq would be part of that loop, and no longer need a vcpu-index parameter.
>
Another note, for this pmu device we don't actually need KVM_CREATE_DEVICE
to be a vcpu ioctl. We can just add another vcpu-init feature flag that we
set with KVM_ARM_VCPU_INIT in order to "create" the pmu. We still need to
add KVM_SET/GET_DEVICE_ATTR to the vcpu ioctl though, allowing the irq to
be set. KVM_ARM_PMU_GRP_IRQ will just become a vcpu attribute.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-07 20:36 ` Andrew Jones
@ 2016-01-09 12:29 ` Christoffer Dall
-1 siblings, 0 replies; 197+ messages in thread
From: Christoffer Dall @ 2016-01-09 12:29 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm-devel, Marc Zyngier, Will Deacon, Shannon Zhao, kvmarm,
arm-mail-list
On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > >>> +
> > >>> +Groups:
> > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > >>> + Attributes:
> > >>> + The attr field of kvm_device_attr encodes one value:
> > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > >>> + values: | reserved | vcpu_index |
> > >>> + A value describing the PMU overflow interrupt number for the specified
> > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > >>
> > >> I see we're using vcpu_index rather than MPIDR affinity value
> > >> for specifying which CPU we're configuring. Is this in line with
> > >> our planned API for GICv3 configuration?
> > >>
> > > Here vcpu_index is used to indexing the vCPU, no special use.
> >
> > Yes, but you can identify the CPU by index, or by its MPIDR.
> > We had a discussion about which was the best way for doing
> > the VGIC API, and I can't remember which way round we ended up
> > going for. Whichever we chose, we should do the same thing here.
>
> I think we should start up a new discussion on this. My understanding,
> after a chat with Igor, who was involved in the untangling of vcpu-id and
> apic-id for x86, is that using vcpu-id is preferred, unless of course
> the device expects an apic-id/mpidr, in which case there's no reason to
> translate it on both sides.
>
I'm fairly strongly convinced that we should use the full 32-bit
compressed MPIDR for everything ARM related going forward, as this will
cover any case required and leverages and architecturally defined way of
uniquely identifying a (v)CPU.
-Christoffer
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-09 12:29 ` Christoffer Dall
0 siblings, 0 replies; 197+ messages in thread
From: Christoffer Dall @ 2016-01-09 12:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > >>> +
> > >>> +Groups:
> > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > >>> + Attributes:
> > >>> + The attr field of kvm_device_attr encodes one value:
> > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > >>> + values: | reserved | vcpu_index |
> > >>> + A value describing the PMU overflow interrupt number for the specified
> > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > >>
> > >> I see we're using vcpu_index rather than MPIDR affinity value
> > >> for specifying which CPU we're configuring. Is this in line with
> > >> our planned API for GICv3 configuration?
> > >>
> > > Here vcpu_index is used to indexing the vCPU, no special use.
> >
> > Yes, but you can identify the CPU by index, or by its MPIDR.
> > We had a discussion about which was the best way for doing
> > the VGIC API, and I can't remember which way round we ended up
> > going for. Whichever we chose, we should do the same thing here.
>
> I think we should start up a new discussion on this. My understanding,
> after a chat with Igor, who was involved in the untangling of vcpu-id and
> apic-id for x86, is that using vcpu-id is preferred, unless of course
> the device expects an apic-id/mpidr, in which case there's no reason to
> translate it on both sides.
>
I'm fairly strongly convinced that we should use the full 32-bit
compressed MPIDR for everything ARM related going forward, as this will
cover any case required and leverages and architecturally defined way of
uniquely identifying a (v)CPU.
-Christoffer
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-09 12:29 ` Christoffer Dall
@ 2016-01-09 15:03 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-09 15:03 UTC (permalink / raw)
To: Christoffer Dall
Cc: Andrew Jones, Peter Maydell, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Sat, 9 Jan 2016 13:29:56 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > >>> +
> > > >>> +Groups:
> > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > >>> + Attributes:
> > > >>> + The attr field of kvm_device_attr encodes one value:
> > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > >>> + values: | reserved | vcpu_index |
> > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > >>
> > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > >> for specifying which CPU we're configuring. Is this in line with
> > > >> our planned API for GICv3 configuration?
> > > >>
> > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > >
> > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > We had a discussion about which was the best way for doing
> > > the VGIC API, and I can't remember which way round we ended up
> > > going for. Whichever we chose, we should do the same thing here.
> >
> > I think we should start up a new discussion on this. My understanding,
> > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > the device expects an apic-id/mpidr, in which case there's no reason to
> > translate it on both sides.
> >
>
> I'm fairly strongly convinced that we should use the full 32-bit
> compressed MPIDR for everything ARM related going forward, as this will
> cover any case required and leverages and architecturally defined way of
> uniquely identifying a (v)CPU.
+1.
vcpu_ids, indexes or any other constructs are just a bunch
of KVM-specific definitions that do not describe the VM from an
architecture PoV. In contrast, the MPIDR is guaranteed to be unique
stable, and identifies a given (v)CPU.
As for the PMU: either 1) we instantiate it together with the CPU
(with a new capability/feature), or 2) we map it to a MPIDR, and
associate it with its vcpu at runtime.
I'm slightly in favor of 1), as it simplifies things a bit, but 2) is
doable as well (GICv3 has similar requirements).
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-09 15:03 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-09 15:03 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 9 Jan 2016 13:29:56 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > >>> +
> > > >>> +Groups:
> > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > >>> + Attributes:
> > > >>> + The attr field of kvm_device_attr encodes one value:
> > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > >>> + values: | reserved | vcpu_index |
> > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > >>
> > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > >> for specifying which CPU we're configuring. Is this in line with
> > > >> our planned API for GICv3 configuration?
> > > >>
> > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > >
> > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > We had a discussion about which was the best way for doing
> > > the VGIC API, and I can't remember which way round we ended up
> > > going for. Whichever we chose, we should do the same thing here.
> >
> > I think we should start up a new discussion on this. My understanding,
> > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > the device expects an apic-id/mpidr, in which case there's no reason to
> > translate it on both sides.
> >
>
> I'm fairly strongly convinced that we should use the full 32-bit
> compressed MPIDR for everything ARM related going forward, as this will
> cover any case required and leverages and architecturally defined way of
> uniquely identifying a (v)CPU.
+1.
vcpu_ids, indexes or any other constructs are just a bunch
of KVM-specific definitions that do not describe the VM from an
architecture PoV. In contrast, the MPIDR is guaranteed to be unique
stable, and identifies a given (v)CPU.
As for the PMU: either 1) we instantiate it together with the CPU
(with a new capability/feature), or 2) we map it to a MPIDR, and
associate it with its vcpu at runtime.
I'm slightly in favor of 1), as it simplifies things a bit, but 2) is
doable as well (GICv3 has similar requirements).
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-09 15:03 ` Marc Zyngier
@ 2016-01-11 8:45 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-11 8:45 UTC (permalink / raw)
To: Marc Zyngier, Christoffer Dall
Cc: Andrew Jones, Peter Maydell, kvmarm, kvm-devel, Will Deacon,
Shannon Zhao, arm-mail-list
On 2016/1/9 23:03, Marc Zyngier wrote:
> On Sat, 9 Jan 2016 13:29:56 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
>> > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>> > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>> > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>>>>> > > > >>> +
>>>>>>> > > > >>> +Groups:
>>>>>>> > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>> > > > >>> + Attributes:
>>>>>>> > > > >>> + The attr field of kvm_device_attr encodes one value:
>>>>>>> > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
>>>>>>> > > > >>> + values: | reserved | vcpu_index |
>>>>>>> > > > >>> + A value describing the PMU overflow interrupt number for the specified
>>>>>>> > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>> > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>> > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>> > > > >>
>>>>>> > > > >> I see we're using vcpu_index rather than MPIDR affinity value
>>>>>> > > > >> for specifying which CPU we're configuring. Is this in line with
>>>>>> > > > >> our planned API for GICv3 configuration?
>>>>>> > > > >>
>>>>> > > > > Here vcpu_index is used to indexing the vCPU, no special use.
>>>> > > >
>>>> > > > Yes, but you can identify the CPU by index, or by its MPIDR.
>>>> > > > We had a discussion about which was the best way for doing
>>>> > > > the VGIC API, and I can't remember which way round we ended up
>>>> > > > going for. Whichever we chose, we should do the same thing here.
>>> > >
>>> > > I think we should start up a new discussion on this. My understanding,
>>> > > after a chat with Igor, who was involved in the untangling of vcpu-id and
>>> > > apic-id for x86, is that using vcpu-id is preferred, unless of course
>>> > > the device expects an apic-id/mpidr, in which case there's no reason to
>>> > > translate it on both sides.
>>> > >
>> >
>> > I'm fairly strongly convinced that we should use the full 32-bit
>> > compressed MPIDR for everything ARM related going forward, as this will
>> > cover any case required and leverages and architecturally defined way of
>> > uniquely identifying a (v)CPU.
> +1.
>
> vcpu_ids, indexes or any other constructs are just a bunch
> of KVM-specific definitions that do not describe the VM from an
> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> stable, and identifies a given (v)CPU.
>
> As for the PMU: either 1) we instantiate it together with the CPU
> (with a new capability/feature),
So spare some bits(e.g. 10 bits) of the features array to pass the PMU
irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 8:45 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-11 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/9 23:03, Marc Zyngier wrote:
> On Sat, 9 Jan 2016 13:29:56 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
>> > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>> > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>> > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>>>>> > > > >>> +
>>>>>>> > > > >>> +Groups:
>>>>>>> > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>> > > > >>> + Attributes:
>>>>>>> > > > >>> + The attr field of kvm_device_attr encodes one value:
>>>>>>> > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
>>>>>>> > > > >>> + values: | reserved | vcpu_index |
>>>>>>> > > > >>> + A value describing the PMU overflow interrupt number for the specified
>>>>>>> > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>> > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>> > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>> > > > >>
>>>>>> > > > >> I see we're using vcpu_index rather than MPIDR affinity value
>>>>>> > > > >> for specifying which CPU we're configuring. Is this in line with
>>>>>> > > > >> our planned API for GICv3 configuration?
>>>>>> > > > >>
>>>>> > > > > Here vcpu_index is used to indexing the vCPU, no special use.
>>>> > > >
>>>> > > > Yes, but you can identify the CPU by index, or by its MPIDR.
>>>> > > > We had a discussion about which was the best way for doing
>>>> > > > the VGIC API, and I can't remember which way round we ended up
>>>> > > > going for. Whichever we chose, we should do the same thing here.
>>> > >
>>> > > I think we should start up a new discussion on this. My understanding,
>>> > > after a chat with Igor, who was involved in the untangling of vcpu-id and
>>> > > apic-id for x86, is that using vcpu-id is preferred, unless of course
>>> > > the device expects an apic-id/mpidr, in which case there's no reason to
>>> > > translate it on both sides.
>>> > >
>> >
>> > I'm fairly strongly convinced that we should use the full 32-bit
>> > compressed MPIDR for everything ARM related going forward, as this will
>> > cover any case required and leverages and architecturally defined way of
>> > uniquely identifying a (v)CPU.
> +1.
>
> vcpu_ids, indexes or any other constructs are just a bunch
> of KVM-specific definitions that do not describe the VM from an
> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> stable, and identifies a given (v)CPU.
>
> As for the PMU: either 1) we instantiate it together with the CPU
> (with a new capability/feature),
So spare some bits(e.g. 10 bits) of the features array to pass the PMU
irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 8:45 ` Shannon Zhao
@ 2016-01-11 8:59 ` Marc Zyngier
-1 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-11 8:59 UTC (permalink / raw)
To: Shannon Zhao, Christoffer Dall
Cc: Andrew Jones, Peter Maydell, kvmarm, kvm-devel, Will Deacon,
Shannon Zhao, arm-mail-list
On 11/01/16 08:45, Shannon Zhao wrote:
>
>
> On 2016/1/9 23:03, Marc Zyngier wrote:
>> On Sat, 9 Jan 2016 13:29:56 +0100
>> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>>
>>>> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>>>>> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>>>>>> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Groups:
>>>>>>>>>>>>>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>>>>>>>>> + Attributes:
>>>>>>>>>>>>>> + The attr field of kvm_device_attr encodes one value:
>>>>>>>>>>>>>> + bits: | 63 .... 32 | 31 .... 0 |
>>>>>>>>>>>>>> + values: | reserved | vcpu_index |
>>>>>>>>>>>>>> + A value describing the PMU overflow interrupt number for the specified
>>>>>>>>>>>>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>>>>>>>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>>>>>>>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>>>>>>>>
>>>>>>>>>>>> I see we're using vcpu_index rather than MPIDR affinity value
>>>>>>>>>>>> for specifying which CPU we're configuring. Is this in line with
>>>>>>>>>>>> our planned API for GICv3 configuration?
>>>>>>>>>>>>
>>>>>>>>>> Here vcpu_index is used to indexing the vCPU, no special use.
>>>>>>>>
>>>>>>>> Yes, but you can identify the CPU by index, or by its MPIDR.
>>>>>>>> We had a discussion about which was the best way for doing
>>>>>>>> the VGIC API, and I can't remember which way round we ended up
>>>>>>>> going for. Whichever we chose, we should do the same thing here.
>>>>>>
>>>>>> I think we should start up a new discussion on this. My understanding,
>>>>>> after a chat with Igor, who was involved in the untangling of vcpu-id and
>>>>>> apic-id for x86, is that using vcpu-id is preferred, unless of course
>>>>>> the device expects an apic-id/mpidr, in which case there's no reason to
>>>>>> translate it on both sides.
>>>>>>
>>>>
>>>> I'm fairly strongly convinced that we should use the full 32-bit
>>>> compressed MPIDR for everything ARM related going forward, as this will
>>>> cover any case required and leverages and architecturally defined way of
>>>> uniquely identifying a (v)CPU.
>> +1.
>>
>> vcpu_ids, indexes or any other constructs are just a bunch
>> of KVM-specific definitions that do not describe the VM from an
>> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
>> stable, and identifies a given (v)CPU.
>>
>> As for the PMU: either 1) we instantiate it together with the CPU
>> (with a new capability/feature),
> So spare some bits(e.g. 10 bits) of the features array to pass the PMU
> irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
Using the device attributes seems more suitable, but I don't know if
using GET/SET_DEVICE_ATTR without the actual creation of a device is
acceptable...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 8:59 ` Marc Zyngier
0 siblings, 0 replies; 197+ messages in thread
From: Marc Zyngier @ 2016-01-11 8:59 UTC (permalink / raw)
To: linux-arm-kernel
On 11/01/16 08:45, Shannon Zhao wrote:
>
>
> On 2016/1/9 23:03, Marc Zyngier wrote:
>> On Sat, 9 Jan 2016 13:29:56 +0100
>> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>>
>>>> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>>>>> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>>>>>> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Groups:
>>>>>>>>>>>>>> + KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>>>>>>>>> + Attributes:
>>>>>>>>>>>>>> + The attr field of kvm_device_attr encodes one value:
>>>>>>>>>>>>>> + bits: | 63 .... 32 | 31 .... 0 |
>>>>>>>>>>>>>> + values: | reserved | vcpu_index |
>>>>>>>>>>>>>> + A value describing the PMU overflow interrupt number for the specified
>>>>>>>>>>>>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>>>>>>>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>>>>>>>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>>>>>>>>
>>>>>>>>>>>> I see we're using vcpu_index rather than MPIDR affinity value
>>>>>>>>>>>> for specifying which CPU we're configuring. Is this in line with
>>>>>>>>>>>> our planned API for GICv3 configuration?
>>>>>>>>>>>>
>>>>>>>>>> Here vcpu_index is used to indexing the vCPU, no special use.
>>>>>>>>
>>>>>>>> Yes, but you can identify the CPU by index, or by its MPIDR.
>>>>>>>> We had a discussion about which was the best way for doing
>>>>>>>> the VGIC API, and I can't remember which way round we ended up
>>>>>>>> going for. Whichever we chose, we should do the same thing here.
>>>>>>
>>>>>> I think we should start up a new discussion on this. My understanding,
>>>>>> after a chat with Igor, who was involved in the untangling of vcpu-id and
>>>>>> apic-id for x86, is that using vcpu-id is preferred, unless of course
>>>>>> the device expects an apic-id/mpidr, in which case there's no reason to
>>>>>> translate it on both sides.
>>>>>>
>>>>
>>>> I'm fairly strongly convinced that we should use the full 32-bit
>>>> compressed MPIDR for everything ARM related going forward, as this will
>>>> cover any case required and leverages and architecturally defined way of
>>>> uniquely identifying a (v)CPU.
>> +1.
>>
>> vcpu_ids, indexes or any other constructs are just a bunch
>> of KVM-specific definitions that do not describe the VM from an
>> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
>> stable, and identifies a given (v)CPU.
>>
>> As for the PMU: either 1) we instantiate it together with the CPU
>> (with a new capability/feature),
> So spare some bits(e.g. 10 bits) of the features array to pass the PMU
> irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
Using the device attributes seems more suitable, but I don't know if
using GET/SET_DEVICE_ATTR without the actual creation of a device is
acceptable...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 8:59 ` Marc Zyngier
@ 2016-01-11 11:52 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 11:52 UTC (permalink / raw)
To: Marc Zyngier
Cc: Shannon Zhao, Christoffer Dall, Peter Maydell, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Mon, Jan 11, 2016 at 08:59:38AM +0000, Marc Zyngier wrote:
> On 11/01/16 08:45, Shannon Zhao wrote:
> >
> >
> > On 2016/1/9 23:03, Marc Zyngier wrote:
> >> On Sat, 9 Jan 2016 13:29:56 +0100
> >> Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >>
> >>>> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> >>>>>> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> >>>>>>>> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> >>>>>>>>>>>>>> +
> >>>>>>>>>>>>>> +Groups:
> >>>>>>>>>>>>>> + KVM_DEV_ARM_PMU_GRP_IRQ
> >>>>>>>>>>>>>> + Attributes:
> >>>>>>>>>>>>>> + The attr field of kvm_device_attr encodes one value:
> >>>>>>>>>>>>>> + bits: | 63 .... 32 | 31 .... 0 |
> >>>>>>>>>>>>>> + values: | reserved | vcpu_index |
> >>>>>>>>>>>>>> + A value describing the PMU overflow interrupt number for the specified
> >>>>>>>>>>>>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >>>>>>>>>>>>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >>>>>>>>>>>>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I see we're using vcpu_index rather than MPIDR affinity value
> >>>>>>>>>>>> for specifying which CPU we're configuring. Is this in line with
> >>>>>>>>>>>> our planned API for GICv3 configuration?
> >>>>>>>>>>>>
> >>>>>>>>>> Here vcpu_index is used to indexing the vCPU, no special use.
> >>>>>>>>
> >>>>>>>> Yes, but you can identify the CPU by index, or by its MPIDR.
> >>>>>>>> We had a discussion about which was the best way for doing
> >>>>>>>> the VGIC API, and I can't remember which way round we ended up
> >>>>>>>> going for. Whichever we chose, we should do the same thing here.
> >>>>>>
> >>>>>> I think we should start up a new discussion on this. My understanding,
> >>>>>> after a chat with Igor, who was involved in the untangling of vcpu-id and
> >>>>>> apic-id for x86, is that using vcpu-id is preferred, unless of course
> >>>>>> the device expects an apic-id/mpidr, in which case there's no reason to
> >>>>>> translate it on both sides.
> >>>>>>
> >>>>
> >>>> I'm fairly strongly convinced that we should use the full 32-bit
> >>>> compressed MPIDR for everything ARM related going forward, as this will
> >>>> cover any case required and leverages and architecturally defined way of
> >>>> uniquely identifying a (v)CPU.
> >> +1.
> >>
> >> vcpu_ids, indexes or any other constructs are just a bunch
> >> of KVM-specific definitions that do not describe the VM from an
> >> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> >> stable, and identifies a given (v)CPU.
> >>
> >> As for the PMU: either 1) we instantiate it together with the CPU
> >> (with a new capability/feature),
> > So spare some bits(e.g. 10 bits) of the features array to pass the PMU
> > irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
>
> Using the device attributes seems more suitable, but I don't know if
> using GET/SET_DEVICE_ATTR without the actual creation of a device is
> acceptable...
There's precedent set by s390 to take only the set/get/has api into a
new context, commit f206165620.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 11:52 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 11:52 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 08:59:38AM +0000, Marc Zyngier wrote:
> On 11/01/16 08:45, Shannon Zhao wrote:
> >
> >
> > On 2016/1/9 23:03, Marc Zyngier wrote:
> >> On Sat, 9 Jan 2016 13:29:56 +0100
> >> Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >>
> >>>> On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> >>>>>> On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> >>>>>>>> On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> >>>>>>>>>>>>>> +
> >>>>>>>>>>>>>> +Groups:
> >>>>>>>>>>>>>> + KVM_DEV_ARM_PMU_GRP_IRQ
> >>>>>>>>>>>>>> + Attributes:
> >>>>>>>>>>>>>> + The attr field of kvm_device_attr encodes one value:
> >>>>>>>>>>>>>> + bits: | 63 .... 32 | 31 .... 0 |
> >>>>>>>>>>>>>> + values: | reserved | vcpu_index |
> >>>>>>>>>>>>>> + A value describing the PMU overflow interrupt number for the specified
> >>>>>>>>>>>>>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> >>>>>>>>>>>>>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> >>>>>>>>>>>>>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I see we're using vcpu_index rather than MPIDR affinity value
> >>>>>>>>>>>> for specifying which CPU we're configuring. Is this in line with
> >>>>>>>>>>>> our planned API for GICv3 configuration?
> >>>>>>>>>>>>
> >>>>>>>>>> Here vcpu_index is used to indexing the vCPU, no special use.
> >>>>>>>>
> >>>>>>>> Yes, but you can identify the CPU by index, or by its MPIDR.
> >>>>>>>> We had a discussion about which was the best way for doing
> >>>>>>>> the VGIC API, and I can't remember which way round we ended up
> >>>>>>>> going for. Whichever we chose, we should do the same thing here.
> >>>>>>
> >>>>>> I think we should start up a new discussion on this. My understanding,
> >>>>>> after a chat with Igor, who was involved in the untangling of vcpu-id and
> >>>>>> apic-id for x86, is that using vcpu-id is preferred, unless of course
> >>>>>> the device expects an apic-id/mpidr, in which case there's no reason to
> >>>>>> translate it on both sides.
> >>>>>>
> >>>>
> >>>> I'm fairly strongly convinced that we should use the full 32-bit
> >>>> compressed MPIDR for everything ARM related going forward, as this will
> >>>> cover any case required and leverages and architecturally defined way of
> >>>> uniquely identifying a (v)CPU.
> >> +1.
> >>
> >> vcpu_ids, indexes or any other constructs are just a bunch
> >> of KVM-specific definitions that do not describe the VM from an
> >> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> >> stable, and identifies a given (v)CPU.
> >>
> >> As for the PMU: either 1) we instantiate it together with the CPU
> >> (with a new capability/feature),
> > So spare some bits(e.g. 10 bits) of the features array to pass the PMU
> > irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
>
> Using the device attributes seems more suitable, but I don't know if
> using GET/SET_DEVICE_ATTR without the actual creation of a device is
> acceptable...
There's precedent set by s390 to take only the set/get/has api into a
new context, commit f206165620.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 11:52 ` Andrew Jones
@ 2016-01-11 12:03 ` Shannon Zhao
-1 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-11 12:03 UTC (permalink / raw)
To: Andrew Jones, Marc Zyngier
Cc: Shannon Zhao, Christoffer Dall, Peter Maydell, kvmarm, kvm-devel,
Will Deacon, arm-mail-list
On 2016/1/11 19:52, Andrew Jones wrote:
> On Mon, Jan 11, 2016 at 08:59:38AM +0000, Marc Zyngier wrote:
>> >On 11/01/16 08:45, Shannon Zhao wrote:
>>> > >
>>> > >
>>> > >On 2016/1/9 23:03, Marc Zyngier wrote:
>>>> > >>On Sat, 9 Jan 2016 13:29:56 +0100
>>>> > >>Christoffer Dall<christoffer.dall@linaro.org> wrote:
>>>> > >>
>>>>>> > >>>>On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>>>>>>> > >>>>>>On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>>>>>>>> > >>>>>>>>On 7 January 2016 at 14:49, Shannon Zhao<zhaoshenglong@huawei.com> wrote:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+Groups:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ Attributes:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ The attr field of kvm_device_attr encodes one value:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ bits: | 63 .... 32 | 31 .... 0 |
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ values: | reserved | vcpu_index |
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ A value describing the PMU overflow interrupt number for the specified
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>>>>>>>>>> > >>>>>>>>>>>>
>>>>>>>>>>>>>> > >>>>>>>>>>>>I see we're using vcpu_index rather than MPIDR affinity value
>>>>>>>>>>>>>> > >>>>>>>>>>>>for specifying which CPU we're configuring. Is this in line with
>>>>>>>>>>>>>> > >>>>>>>>>>>>our planned API for GICv3 configuration?
>>>>>>>>>>>>>> > >>>>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>>Here vcpu_index is used to indexing the vCPU, no special use.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>>Yes, but you can identify the CPU by index, or by its MPIDR.
>>>>>>>>>> > >>>>>>>>We had a discussion about which was the best way for doing
>>>>>>>>>> > >>>>>>>>the VGIC API, and I can't remember which way round we ended up
>>>>>>>>>> > >>>>>>>>going for. Whichever we chose, we should do the same thing here.
>>>>>>>> > >>>>>>
>>>>>>>> > >>>>>>I think we should start up a new discussion on this. My understanding,
>>>>>>>> > >>>>>>after a chat with Igor, who was involved in the untangling of vcpu-id and
>>>>>>>> > >>>>>>apic-id for x86, is that using vcpu-id is preferred, unless of course
>>>>>>>> > >>>>>>the device expects an apic-id/mpidr, in which case there's no reason to
>>>>>>>> > >>>>>>translate it on both sides.
>>>>>>>> > >>>>>>
>>>>>> > >>>>
>>>>>> > >>>>I'm fairly strongly convinced that we should use the full 32-bit
>>>>>> > >>>>compressed MPIDR for everything ARM related going forward, as this will
>>>>>> > >>>>cover any case required and leverages and architecturally defined way of
>>>>>> > >>>>uniquely identifying a (v)CPU.
>>>> > >>+1.
>>>> > >>
>>>> > >>vcpu_ids, indexes or any other constructs are just a bunch
>>>> > >>of KVM-specific definitions that do not describe the VM from an
>>>> > >>architecture PoV. In contrast, the MPIDR is guaranteed to be unique
>>>> > >>stable, and identifies a given (v)CPU.
>>>> > >>
>>>> > >>As for the PMU: either 1) we instantiate it together with the CPU
>>>> > >>(with a new capability/feature),
>>> > >So spare some bits(e.g. 10 bits) of the features array to pass the PMU
>>> > >irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
>> >
>> >Using the device attributes seems more suitable, but I don't know if
>> >using GET/SET_DEVICE_ATTR without the actual creation of a device is
>> >acceptable...
> There's precedent set by s390 to take only the set/get/has api into a
> new context, commit f206165620.
Thanks Andrew. So adding the set/get/has api for only ARM VCPU is
acceptable? If so, I'll rewrite my patch.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 12:03 ` Shannon Zhao
0 siblings, 0 replies; 197+ messages in thread
From: Shannon Zhao @ 2016-01-11 12:03 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/11 19:52, Andrew Jones wrote:
> On Mon, Jan 11, 2016 at 08:59:38AM +0000, Marc Zyngier wrote:
>> >On 11/01/16 08:45, Shannon Zhao wrote:
>>> > >
>>> > >
>>> > >On 2016/1/9 23:03, Marc Zyngier wrote:
>>>> > >>On Sat, 9 Jan 2016 13:29:56 +0100
>>>> > >>Christoffer Dall<christoffer.dall@linaro.org> wrote:
>>>> > >>
>>>>>> > >>>>On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
>>>>>>>> > >>>>>>On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
>>>>>>>>>> > >>>>>>>>On 7 January 2016 at 14:49, Shannon Zhao<zhaoshenglong@huawei.com> wrote:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+Groups:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ KVM_DEV_ARM_PMU_GRP_IRQ
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ Attributes:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ The attr field of kvm_device_attr encodes one value:
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ bits: | 63 .... 32 | 31 .... 0 |
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ values: | reserved | vcpu_index |
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ A value describing the PMU overflow interrupt number for the specified
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ interrupt type must be same for each vcpu. As a PPI, the interrupt number is
>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>+ same for all vcpus, while as a SPI it must be different for each vcpu.
>>>>>>>>>>>>>> > >>>>>>>>>>>>
>>>>>>>>>>>>>> > >>>>>>>>>>>>I see we're using vcpu_index rather than MPIDR affinity value
>>>>>>>>>>>>>> > >>>>>>>>>>>>for specifying which CPU we're configuring. Is this in line with
>>>>>>>>>>>>>> > >>>>>>>>>>>>our planned API for GICv3 configuration?
>>>>>>>>>>>>>> > >>>>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>>Here vcpu_index is used to indexing the vCPU, no special use.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>>Yes, but you can identify the CPU by index, or by its MPIDR.
>>>>>>>>>> > >>>>>>>>We had a discussion about which was the best way for doing
>>>>>>>>>> > >>>>>>>>the VGIC API, and I can't remember which way round we ended up
>>>>>>>>>> > >>>>>>>>going for. Whichever we chose, we should do the same thing here.
>>>>>>>> > >>>>>>
>>>>>>>> > >>>>>>I think we should start up a new discussion on this. My understanding,
>>>>>>>> > >>>>>>after a chat with Igor, who was involved in the untangling of vcpu-id and
>>>>>>>> > >>>>>>apic-id for x86, is that using vcpu-id is preferred, unless of course
>>>>>>>> > >>>>>>the device expects an apic-id/mpidr, in which case there's no reason to
>>>>>>>> > >>>>>>translate it on both sides.
>>>>>>>> > >>>>>>
>>>>>> > >>>>
>>>>>> > >>>>I'm fairly strongly convinced that we should use the full 32-bit
>>>>>> > >>>>compressed MPIDR for everything ARM related going forward, as this will
>>>>>> > >>>>cover any case required and leverages and architecturally defined way of
>>>>>> > >>>>uniquely identifying a (v)CPU.
>>>> > >>+1.
>>>> > >>
>>>> > >>vcpu_ids, indexes or any other constructs are just a bunch
>>>> > >>of KVM-specific definitions that do not describe the VM from an
>>>> > >>architecture PoV. In contrast, the MPIDR is guaranteed to be unique
>>>> > >>stable, and identifies a given (v)CPU.
>>>> > >>
>>>> > >>As for the PMU: either 1) we instantiate it together with the CPU
>>>> > >>(with a new capability/feature),
>>> > >So spare some bits(e.g. 10 bits) of the features array to pass the PMU
>>> > >irq number or add KVM_SET/GET_DEVICE_ATTR for vcpu ioctl?
>> >
>> >Using the device attributes seems more suitable, but I don't know if
>> >using GET/SET_DEVICE_ATTR without the actual creation of a device is
>> >acceptable...
> There's precedent set by s390 to take only the set/get/has api into a
> new context, commit f206165620.
Thanks Andrew. So adding the set/get/has api for only ARM VCPU is
acceptable? If so, I'll rewrite my patch.
Thanks,
--
Shannon
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-09 15:03 ` Marc Zyngier
@ 2016-01-11 14:07 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 14:07 UTC (permalink / raw)
To: Marc Zyngier
Cc: Christoffer Dall, Peter Maydell, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> On Sat, 9 Jan 2016 13:29:56 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
> > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > >>> +
> > > > >>> +Groups:
> > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > >>> + Attributes:
> > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > >>> + values: | reserved | vcpu_index |
> > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > >>
> > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > >> our planned API for GICv3 configuration?
> > > > >>
> > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > >
> > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > We had a discussion about which was the best way for doing
> > > > the VGIC API, and I can't remember which way round we ended up
> > > > going for. Whichever we chose, we should do the same thing here.
> > >
> > > I think we should start up a new discussion on this. My understanding,
> > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > translate it on both sides.
> > >
> >
> > I'm fairly strongly convinced that we should use the full 32-bit
> > compressed MPIDR for everything ARM related going forward, as this will
> > cover any case required and leverages and architecturally defined way of
> > uniquely identifying a (v)CPU.
>
> +1.
>
> vcpu_ids, indexes or any other constructs are just a bunch
> of KVM-specific definitions that do not describe the VM from an
> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> stable, and identifies a given (v)CPU.
>
cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
in real hardware, to allow us to match emulation code to specs and keep
sanity. But I assume those are the only places of "everything" you guys
are referring to, as everywhere else we should stick to using the concept
of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
from needing all the data structures to be large, complex, sparse things.
Identifiers separate from MPIDR also allow hotunplug/plug to more easily
reuse resources, i.e. remap indices to other vcpus as necessary.
In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
use here isn't based on a hardware spec, so there's nowhere to look for
how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
as well use the easiest to use unique identifier.
That said, I like the vcpu ioctl method much better. With that we avoid
the need for vcpu identifiers all together. I'm even having third
thoughts about the gic per vcpu registers. If we go with extending
GET/SET_DEVICE_ATTR here, then I think we should do the same there as
well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
anyway.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 14:07 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 14:07 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> On Sat, 9 Jan 2016 13:29:56 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
> > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > >>> +
> > > > >>> +Groups:
> > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > >>> + Attributes:
> > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > >>> + values: | reserved | vcpu_index |
> > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > >>
> > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > >> our planned API for GICv3 configuration?
> > > > >>
> > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > >
> > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > We had a discussion about which was the best way for doing
> > > > the VGIC API, and I can't remember which way round we ended up
> > > > going for. Whichever we chose, we should do the same thing here.
> > >
> > > I think we should start up a new discussion on this. My understanding,
> > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > translate it on both sides.
> > >
> >
> > I'm fairly strongly convinced that we should use the full 32-bit
> > compressed MPIDR for everything ARM related going forward, as this will
> > cover any case required and leverages and architecturally defined way of
> > uniquely identifying a (v)CPU.
>
> +1.
>
> vcpu_ids, indexes or any other constructs are just a bunch
> of KVM-specific definitions that do not describe the VM from an
> architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> stable, and identifies a given (v)CPU.
>
cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
in real hardware, to allow us to match emulation code to specs and keep
sanity. But I assume those are the only places of "everything" you guys
are referring to, as everywhere else we should stick to using the concept
of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
from needing all the data structures to be large, complex, sparse things.
Identifiers separate from MPIDR also allow hotunplug/plug to more easily
reuse resources, i.e. remap indices to other vcpus as necessary.
In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
use here isn't based on a hardware spec, so there's nowhere to look for
how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
as well use the easiest to use unique identifier.
That said, I like the vcpu ioctl method much better. With that we avoid
the need for vcpu identifiers all together. I'm even having third
thoughts about the gic per vcpu registers. If we go with extending
GET/SET_DEVICE_ATTR here, then I think we should do the same there as
well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
anyway.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 14:07 ` Andrew Jones
@ 2016-01-11 15:09 ` Christoffer Dall
-1 siblings, 0 replies; 197+ messages in thread
From: Christoffer Dall @ 2016-01-11 15:09 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm-devel, Marc Zyngier, Will Deacon, Shannon Zhao, kvmarm,
arm-mail-list
On Mon, Jan 11, 2016 at 03:07:17PM +0100, Andrew Jones wrote:
> On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> > On Sat, 9 Jan 2016 13:29:56 +0100
> > Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >
> > > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > > >>> +
> > > > > >>> +Groups:
> > > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > > >>> + Attributes:
> > > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > > >>> + values: | reserved | vcpu_index |
> > > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > > >>
> > > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > > >> our planned API for GICv3 configuration?
> > > > > >>
> > > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > > >
> > > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > > We had a discussion about which was the best way for doing
> > > > > the VGIC API, and I can't remember which way round we ended up
> > > > > going for. Whichever we chose, we should do the same thing here.
> > > >
> > > > I think we should start up a new discussion on this. My understanding,
> > > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > > translate it on both sides.
> > > >
> > >
> > > I'm fairly strongly convinced that we should use the full 32-bit
> > > compressed MPIDR for everything ARM related going forward, as this will
> > > cover any case required and leverages and architecturally defined way of
> > > uniquely identifying a (v)CPU.
> >
> > +1.
> >
> > vcpu_ids, indexes or any other constructs are just a bunch
> > of KVM-specific definitions that do not describe the VM from an
> > architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> > stable, and identifies a given (v)CPU.
> >
>
> cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
> in real hardware, to allow us to match emulation code to specs and keep
> sanity. But I assume those are the only places of "everything" you guys
> are referring to, as everywhere else we should stick to using the concept
> of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
> from needing all the data structures to be large, complex, sparse things.
> Identifiers separate from MPIDR also allow hotunplug/plug to more easily
> reuse resources, i.e. remap indices to other vcpus as necessary.
Are vcpu ids already exposed to userspace (beyond the stupid
KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
format they have?
If not, I think decoupling an internal ID and uniquely identifying a CPU
is a good idea.
>
> In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
> userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
> use here isn't based on a hardware spec, so there's nowhere to look for
> how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
> as well use the easiest to use unique identifier.
I think the only things that should matter here are (in no particular
order):
- Userspace convenience
- Clarity
- Avoiding ambiguity
>
> That said, I like the vcpu ioctl method much better. With that we avoid
> the need for vcpu identifiers all together. I'm even having third
> thoughts about the gic per vcpu registers. If we go with extending
> GET/SET_DEVICE_ATTR here, then I think we should do the same there as
> well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
> with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
> anyway.
>
For the GIC, I think we've discussed this in the past. It really
depends whether you think about the GIC as one device (the distributor)
separate from the CPUs, with a bunch of separate devices attached to
each CPU and wired together somehow, or if you think of this as one big
coherent thing where parts of the device are specific to each CPU.
I tend to interpret the GIC as the latter and I think the kernel and
userspace implementations are also done that way, suggesting we should
stick with the device API for all GIC-related state (as was also the
suggestion for the GICv3 save/restore API).
Similarly, because the GIC architecture refers to CPUs using the MPIDR,
we should do the same in this interface. Otherwise, I think you have to
define stricly how the exposed VCPU ID maps to an MPIDR somehow.
-Christoffer
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 15:09 ` Christoffer Dall
0 siblings, 0 replies; 197+ messages in thread
From: Christoffer Dall @ 2016-01-11 15:09 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 03:07:17PM +0100, Andrew Jones wrote:
> On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> > On Sat, 9 Jan 2016 13:29:56 +0100
> > Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >
> > > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > > >>> +
> > > > > >>> +Groups:
> > > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > > >>> + Attributes:
> > > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > > >>> + values: | reserved | vcpu_index |
> > > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > > >>
> > > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > > >> our planned API for GICv3 configuration?
> > > > > >>
> > > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > > >
> > > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > > We had a discussion about which was the best way for doing
> > > > > the VGIC API, and I can't remember which way round we ended up
> > > > > going for. Whichever we chose, we should do the same thing here.
> > > >
> > > > I think we should start up a new discussion on this. My understanding,
> > > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > > translate it on both sides.
> > > >
> > >
> > > I'm fairly strongly convinced that we should use the full 32-bit
> > > compressed MPIDR for everything ARM related going forward, as this will
> > > cover any case required and leverages and architecturally defined way of
> > > uniquely identifying a (v)CPU.
> >
> > +1.
> >
> > vcpu_ids, indexes or any other constructs are just a bunch
> > of KVM-specific definitions that do not describe the VM from an
> > architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> > stable, and identifies a given (v)CPU.
> >
>
> cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
> in real hardware, to allow us to match emulation code to specs and keep
> sanity. But I assume those are the only places of "everything" you guys
> are referring to, as everywhere else we should stick to using the concept
> of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
> from needing all the data structures to be large, complex, sparse things.
> Identifiers separate from MPIDR also allow hotunplug/plug to more easily
> reuse resources, i.e. remap indices to other vcpus as necessary.
Are vcpu ids already exposed to userspace (beyond the stupid
KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
format they have?
If not, I think decoupling an internal ID and uniquely identifying a CPU
is a good idea.
>
> In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
> userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
> use here isn't based on a hardware spec, so there's nowhere to look for
> how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
> as well use the easiest to use unique identifier.
I think the only things that should matter here are (in no particular
order):
- Userspace convenience
- Clarity
- Avoiding ambiguity
>
> That said, I like the vcpu ioctl method much better. With that we avoid
> the need for vcpu identifiers all together. I'm even having third
> thoughts about the gic per vcpu registers. If we go with extending
> GET/SET_DEVICE_ATTR here, then I think we should do the same there as
> well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
> with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
> anyway.
>
For the GIC, I think we've discussed this in the past. It really
depends whether you think about the GIC as one device (the distributor)
separate from the CPUs, with a bunch of separate devices attached to
each CPU and wired together somehow, or if you think of this as one big
coherent thing where parts of the device are specific to each CPU.
I tend to interpret the GIC as the latter and I think the kernel and
userspace implementations are also done that way, suggesting we should
stick with the device API for all GIC-related state (as was also the
suggestion for the GICv3 save/restore API).
Similarly, because the GIC architecture refers to CPUs using the MPIDR,
we should do the same in this interface. Otherwise, I think you have to
define stricly how the exposed VCPU ID maps to an MPIDR somehow.
-Christoffer
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 15:09 ` Christoffer Dall
@ 2016-01-11 16:09 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:09 UTC (permalink / raw)
To: Christoffer Dall
Cc: Marc Zyngier, Peter Maydell, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> On Mon, Jan 11, 2016 at 03:07:17PM +0100, Andrew Jones wrote:
> > On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> > > On Sat, 9 Jan 2016 13:29:56 +0100
> > > Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > >
> > > > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > > > >>> +
> > > > > > >>> +Groups:
> > > > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > > > >>> + Attributes:
> > > > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > > > >>> + values: | reserved | vcpu_index |
> > > > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > > > >>
> > > > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > > > >> our planned API for GICv3 configuration?
> > > > > > >>
> > > > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > > > >
> > > > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > > > We had a discussion about which was the best way for doing
> > > > > > the VGIC API, and I can't remember which way round we ended up
> > > > > > going for. Whichever we chose, we should do the same thing here.
> > > > >
> > > > > I think we should start up a new discussion on this. My understanding,
> > > > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > > > translate it on both sides.
> > > > >
> > > >
> > > > I'm fairly strongly convinced that we should use the full 32-bit
> > > > compressed MPIDR for everything ARM related going forward, as this will
> > > > cover any case required and leverages and architecturally defined way of
> > > > uniquely identifying a (v)CPU.
> > >
> > > +1.
> > >
> > > vcpu_ids, indexes or any other constructs are just a bunch
> > > of KVM-specific definitions that do not describe the VM from an
> > > architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> > > stable, and identifies a given (v)CPU.
> > >
> >
> > cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
> > in real hardware, to allow us to match emulation code to specs and keep
> > sanity. But I assume those are the only places of "everything" you guys
> > are referring to, as everywhere else we should stick to using the concept
> > of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
> > from needing all the data structures to be large, complex, sparse things.
> > Identifiers separate from MPIDR also allow hotunplug/plug to more easily
> > reuse resources, i.e. remap indices to other vcpus as necessary.
>
> Are vcpu ids already exposed to userspace (beyond the stupid
> KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> format they have?
The only other place I found is KVM_CREATE_VCPU. I suppose we could move
to MPIDR for that, and it would be a nice way to handle the "userspace
determines MPIDR" work that I plan to do. Both KVM and its userspaces
would still use some counter-based vcpu identifiers internally, to avoid
large, sparse structures, but I guess the advantage is that they don't
have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
is already 32-bits, and is supposed to be an arbitrary identifier. That
all looks good for converting to MPIDR.
>
> If not, I think decoupling an internal ID and uniquely identifying a CPU
> is a good idea.
>
> >
> > In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
> > userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
> > use here isn't based on a hardware spec, so there's nowhere to look for
> > how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
> > as well use the easiest to use unique identifier.
>
> I think the only things that should matter here are (in no particular
> order):
> - Userspace convenience
> - Clarity
> - Avoiding ambiguity
Agreed. I believe the counter-based vcpu-id brings the most convenience
for any non-MPIDR based APIs, i.e. no spec saying MPIDR should be used.
However, picking which counter-based vcpu-id (if more than one exist)
costs both convenience and clarity. I guess that's another argument for
switching to MPIDR...
>
> >
> > That said, I like the vcpu ioctl method much better. With that we avoid
> > the need for vcpu identifiers all together. I'm even having third
> > thoughts about the gic per vcpu registers. If we go with extending
> > GET/SET_DEVICE_ATTR here, then I think we should do the same there as
> > well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
> > with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
> > anyway.
> >
> For the GIC, I think we've discussed this in the past. It really
> depends whether you think about the GIC as one device (the distributor)
> separate from the CPUs, with a bunch of separate devices attached to
> each CPU and wired together somehow, or if you think of this as one big
> coherent thing where parts of the device are specific to each CPU.
I keep flip-flopping my view, which is why I keep flip-flopping my
opinion on how to deal with its register API :-)
>
> I tend to interpret the GIC as the latter and I think the kernel and
> userspace implementations are also done that way, suggesting we should
> stick with the device API for all GIC-related state (as was also the
> suggestion for the GICv3 save/restore API).
I think the save/restore case is where I always flip to seeing it as a
bunch of separate per cpu devices. It would feel better to me to
save/restore the cpu-gic registers the same way we do all other cpu
registers.
I think we can get the best of both worlds by extending the
SET/GET_DEVICE_ATTR to vcpus, and then using both the device ioctl
and the vcpu ioctls.
>
> Similarly, because the GIC architecture refers to CPUs using the MPIDR,
> we should do the same in this interface. Otherwise, I think you have to
> define stricly how the exposed VCPU ID maps to an MPIDR somehow.
Well, we're creating our own interface to a gic model, so there's
nothing in the spec that says MPIDR is needed here, but if there's
no good reason not to change the KVM_CREATE_VCPU vcpu-id to MPIDR,
then we certainly wouldn't want to invent a new vcpu-id for this use.
My current feelings are:
1) avoid needing vcpu identifiers (use vcpu ioctl whenever possible)
2) if we need them, they should match the same one used by
KVM_CREATE_VCPU (whenever possible)
3) any device api that doesn't provide a 32-bit identifier field
should just be special-cased, and have plenty of documentation
explaining how to handle it - explaining what other limitations
it puts on the guest, etc.
None of those feelings exclude using MPIDR as _the_ vcpu-id (I don't
think). It appears the main benefit of switching to MPIDR would be to
decouple KVM from its userspaces wrt to choosing the non-MPIDR vcpu
identification used for managing data structures and looping over
vcpus internally. We also gain a clean way for userspace to choose
the MPIDR for each vcpu, which we need to do anyway.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:09 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:09 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> On Mon, Jan 11, 2016 at 03:07:17PM +0100, Andrew Jones wrote:
> > On Sat, Jan 09, 2016 at 03:03:39PM +0000, Marc Zyngier wrote:
> > > On Sat, 9 Jan 2016 13:29:56 +0100
> > > Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > >
> > > > On Thu, Jan 07, 2016 at 09:36:47PM +0100, Andrew Jones wrote:
> > > > > On Thu, Jan 07, 2016 at 02:56:15PM +0000, Peter Maydell wrote:
> > > > > > On 7 January 2016 at 14:49, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > > > > > >>> +
> > > > > > >>> +Groups:
> > > > > > >>> + KVM_DEV_ARM_PMU_GRP_IRQ
> > > > > > >>> + Attributes:
> > > > > > >>> + The attr field of kvm_device_attr encodes one value:
> > > > > > >>> + bits: | 63 .... 32 | 31 .... 0 |
> > > > > > >>> + values: | reserved | vcpu_index |
> > > > > > >>> + A value describing the PMU overflow interrupt number for the specified
> > > > > > >>> + vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one VM the
> > > > > > >>> + interrupt type must be same for each vcpu. As a PPI, the interrupt number is
> > > > > > >>> + same for all vcpus, while as a SPI it must be different for each vcpu.
> > > > > > >>
> > > > > > >> I see we're using vcpu_index rather than MPIDR affinity value
> > > > > > >> for specifying which CPU we're configuring. Is this in line with
> > > > > > >> our planned API for GICv3 configuration?
> > > > > > >>
> > > > > > > Here vcpu_index is used to indexing the vCPU, no special use.
> > > > > >
> > > > > > Yes, but you can identify the CPU by index, or by its MPIDR.
> > > > > > We had a discussion about which was the best way for doing
> > > > > > the VGIC API, and I can't remember which way round we ended up
> > > > > > going for. Whichever we chose, we should do the same thing here.
> > > > >
> > > > > I think we should start up a new discussion on this. My understanding,
> > > > > after a chat with Igor, who was involved in the untangling of vcpu-id and
> > > > > apic-id for x86, is that using vcpu-id is preferred, unless of course
> > > > > the device expects an apic-id/mpidr, in which case there's no reason to
> > > > > translate it on both sides.
> > > > >
> > > >
> > > > I'm fairly strongly convinced that we should use the full 32-bit
> > > > compressed MPIDR for everything ARM related going forward, as this will
> > > > cover any case required and leverages and architecturally defined way of
> > > > uniquely identifying a (v)CPU.
> > >
> > > +1.
> > >
> > > vcpu_ids, indexes or any other constructs are just a bunch
> > > of KVM-specific definitions that do not describe the VM from an
> > > architecture PoV. In contrast, the MPIDR is guaranteed to be unique
> > > stable, and identifies a given (v)CPU.
> > >
> >
> > cpu-cpu and cpu-device interfaces should certainly use MPIDR, if they do
> > in real hardware, to allow us to match emulation code to specs and keep
> > sanity. But I assume those are the only places of "everything" you guys
> > are referring to, as everywhere else we should stick to using the concept
> > of vcpu-ids/indices. Since vcpu-indices are just counters they keep us
> > from needing all the data structures to be large, complex, sparse things.
> > Identifiers separate from MPIDR also allow hotunplug/plug to more easily
> > reuse resources, i.e. remap indices to other vcpus as necessary.
>
> Are vcpu ids already exposed to userspace (beyond the stupid
> KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> format they have?
The only other place I found is KVM_CREATE_VCPU. I suppose we could move
to MPIDR for that, and it would be a nice way to handle the "userspace
determines MPIDR" work that I plan to do. Both KVM and its userspaces
would still use some counter-based vcpu identifiers internally, to avoid
large, sparse structures, but I guess the advantage is that they don't
have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
is already 32-bits, and is supposed to be an arbitrary identifier. That
all looks good for converting to MPIDR.
>
> If not, I think decoupling an internal ID and uniquely identifying a CPU
> is a good idea.
>
> >
> > In the PMU case above it seems better to use a vcpu-index. KVM and KVM's
> > userspace both have unique vcpu-indices and unique MPIDRs per vcpu. The
> > use here isn't based on a hardware spec, so there's nowhere to look for
> > how MPIDR should/shouldn't be used. This is just a KVM spec. Here we might
> > as well use the easiest to use unique identifier.
>
> I think the only things that should matter here are (in no particular
> order):
> - Userspace convenience
> - Clarity
> - Avoiding ambiguity
Agreed. I believe the counter-based vcpu-id brings the most convenience
for any non-MPIDR based APIs, i.e. no spec saying MPIDR should be used.
However, picking which counter-based vcpu-id (if more than one exist)
costs both convenience and clarity. I guess that's another argument for
switching to MPIDR...
>
> >
> > That said, I like the vcpu ioctl method much better. With that we avoid
> > the need for vcpu identifiers all together. I'm even having third
> > thoughts about the gic per vcpu registers. If we go with extending
> > GET/SET_DEVICE_ATTR here, then I think we should do the same there as
> > well. That would then leave only KVM_IRQ_LINE using a vcpu-index, which,
> > with its 8-bit vcpu-index, we've outgrown for gicv3 machine types already
> > anyway.
> >
> For the GIC, I think we've discussed this in the past. It really
> depends whether you think about the GIC as one device (the distributor)
> separate from the CPUs, with a bunch of separate devices attached to
> each CPU and wired together somehow, or if you think of this as one big
> coherent thing where parts of the device are specific to each CPU.
I keep flip-flopping my view, which is why I keep flip-flopping my
opinion on how to deal with its register API :-)
>
> I tend to interpret the GIC as the latter and I think the kernel and
> userspace implementations are also done that way, suggesting we should
> stick with the device API for all GIC-related state (as was also the
> suggestion for the GICv3 save/restore API).
I think the save/restore case is where I always flip to seeing it as a
bunch of separate per cpu devices. It would feel better to me to
save/restore the cpu-gic registers the same way we do all other cpu
registers.
I think we can get the best of both worlds by extending the
SET/GET_DEVICE_ATTR to vcpus, and then using both the device ioctl
and the vcpu ioctls.
>
> Similarly, because the GIC architecture refers to CPUs using the MPIDR,
> we should do the same in this interface. Otherwise, I think you have to
> define stricly how the exposed VCPU ID maps to an MPIDR somehow.
Well, we're creating our own interface to a gic model, so there's
nothing in the spec that says MPIDR is needed here, but if there's
no good reason not to change the KVM_CREATE_VCPU vcpu-id to MPIDR,
then we certainly wouldn't want to invent a new vcpu-id for this use.
My current feelings are:
1) avoid needing vcpu identifiers (use vcpu ioctl whenever possible)
2) if we need them, they should match the same one used by
KVM_CREATE_VCPU (whenever possible)
3) any device api that doesn't provide a 32-bit identifier field
should just be special-cased, and have plenty of documentation
explaining how to handle it - explaining what other limitations
it puts on the guest, etc.
None of those feelings exclude using MPIDR as _the_ vcpu-id (I don't
think). It appears the main benefit of switching to MPIDR would be to
decouple KVM from its userspaces wrt to choosing the non-MPIDR vcpu
identification used for managing data structures and looping over
vcpus internally. We also gain a clean way for userspace to choose
the MPIDR for each vcpu, which we need to do anyway.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 16:09 ` Andrew Jones
@ 2016-01-11 16:13 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-11 16:13 UTC (permalink / raw)
To: Andrew Jones
Cc: Christoffer Dall, Marc Zyngier, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On 11 January 2016 at 16:09, Andrew Jones <drjones@redhat.com> wrote:
> I think the save/restore case is where I always flip to seeing it as a
> bunch of separate per cpu devices. It would feel better to me to
> save/restore the cpu-gic registers the same way we do all other cpu
> registers.
>From QEMU's point of view this would be extremely awkward, which
is one reason I'm happy with the GICv3 API we came up with
and reviewed last year...
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:13 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-11 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On 11 January 2016 at 16:09, Andrew Jones <drjones@redhat.com> wrote:
> I think the save/restore case is where I always flip to seeing it as a
> bunch of separate per cpu devices. It would feel better to me to
> save/restore the cpu-gic registers the same way we do all other cpu
> registers.
>From QEMU's point of view this would be extremely awkward, which
is one reason I'm happy with the GICv3 API we came up with
and reviewed last year...
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 16:09 ` Andrew Jones
@ 2016-01-11 16:21 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:21 UTC (permalink / raw)
To: Christoffer Dall
Cc: Marc Zyngier, Peter Maydell, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> > Are vcpu ids already exposed to userspace (beyond the stupid
> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> > format they have?
>
> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
> to MPIDR for that, and it would be a nice way to handle the "userspace
> determines MPIDR" work that I plan to do. Both KVM and its userspaces
> would still use some counter-based vcpu identifiers internally, to avoid
> large, sparse structures, but I guess the advantage is that they don't
> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
> is already 32-bits, and is supposed to be an arbitrary identifier. That
> all looks good for converting to MPIDR.
>
Correction. I understand that vcpu-id is "supposed" to be an arbitrary
identifier now, but it doesn't appear that all the assumptions that it's
a counter are gone yet... virt/kvm/kvm_main.c has
static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
...
if (id >= KVM_MAX_VCPUS)
return -EINVAL;
More to do there I guess...
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:21 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:21 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> > Are vcpu ids already exposed to userspace (beyond the stupid
> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> > format they have?
>
> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
> to MPIDR for that, and it would be a nice way to handle the "userspace
> determines MPIDR" work that I plan to do. Both KVM and its userspaces
> would still use some counter-based vcpu identifiers internally, to avoid
> large, sparse structures, but I guess the advantage is that they don't
> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
> is already 32-bits, and is supposed to be an arbitrary identifier. That
> all looks good for converting to MPIDR.
>
Correction. I understand that vcpu-id is "supposed" to be an arbitrary
identifier now, but it doesn't appear that all the assumptions that it's
a counter are gone yet... virt/kvm/kvm_main.c has
static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
...
if (id >= KVM_MAX_VCPUS)
return -EINVAL;
More to do there I guess...
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 16:21 ` Andrew Jones
@ 2016-01-11 16:29 ` Peter Maydell
-1 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-11 16:29 UTC (permalink / raw)
To: Andrew Jones
Cc: Christoffer Dall, Marc Zyngier, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On 11 January 2016 at 16:21, Andrew Jones <drjones@redhat.com> wrote:
> On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
>> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
>> > Are vcpu ids already exposed to userspace (beyond the stupid
>> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
>> > format they have?
>>
>> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
>> to MPIDR for that, and it would be a nice way to handle the "userspace
>> determines MPIDR" work that I plan to do. Both KVM and its userspaces
>> would still use some counter-based vcpu identifiers internally, to avoid
>> large, sparse structures, but I guess the advantage is that they don't
>> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
>> is already 32-bits, and is supposed to be an arbitrary identifier. That
>> all looks good for converting to MPIDR.
>>
>
> Correction. I understand that vcpu-id is "supposed" to be an arbitrary
> identifier now, but it doesn't appear that all the assumptions that it's
> a counter are gone yet... virt/kvm/kvm_main.c has
>
> static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
> ...
> if (id >= KVM_MAX_VCPUS)
> return -EINVAL;
I think the last time we talked about supporting "userspace
determines MPIDR" the idea was to do it by allowing userspace to
write to the MPIDR register with KVM_SET_ONE_REG. So you'd
create a bunch of CPUs with vcpu-ids as usual, and then the
MPIDRs would be set for them later as appropriate (or not
at all, if userspace was an older qemu).
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:29 ` Peter Maydell
0 siblings, 0 replies; 197+ messages in thread
From: Peter Maydell @ 2016-01-11 16:29 UTC (permalink / raw)
To: linux-arm-kernel
On 11 January 2016 at 16:21, Andrew Jones <drjones@redhat.com> wrote:
> On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
>> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
>> > Are vcpu ids already exposed to userspace (beyond the stupid
>> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
>> > format they have?
>>
>> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
>> to MPIDR for that, and it would be a nice way to handle the "userspace
>> determines MPIDR" work that I plan to do. Both KVM and its userspaces
>> would still use some counter-based vcpu identifiers internally, to avoid
>> large, sparse structures, but I guess the advantage is that they don't
>> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
>> is already 32-bits, and is supposed to be an arbitrary identifier. That
>> all looks good for converting to MPIDR.
>>
>
> Correction. I understand that vcpu-id is "supposed" to be an arbitrary
> identifier now, but it doesn't appear that all the assumptions that it's
> a counter are gone yet... virt/kvm/kvm_main.c has
>
> static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
> ...
> if (id >= KVM_MAX_VCPUS)
> return -EINVAL;
I think the last time we talked about supporting "userspace
determines MPIDR" the idea was to do it by allowing userspace to
write to the MPIDR register with KVM_SET_ONE_REG. So you'd
create a bunch of CPUs with vcpu-ids as usual, and then the
MPIDRs would be set for them later as appropriate (or not
at all, if userspace was an older qemu).
thanks
-- PMM
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 16:29 ` Peter Maydell
@ 2016-01-11 16:44 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:44 UTC (permalink / raw)
To: Peter Maydell
Cc: Christoffer Dall, Marc Zyngier, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Mon, Jan 11, 2016 at 04:29:03PM +0000, Peter Maydell wrote:
> On 11 January 2016 at 16:21, Andrew Jones <drjones@redhat.com> wrote:
> > On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
> >> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> >> > Are vcpu ids already exposed to userspace (beyond the stupid
> >> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> >> > format they have?
> >>
> >> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
> >> to MPIDR for that, and it would be a nice way to handle the "userspace
> >> determines MPIDR" work that I plan to do. Both KVM and its userspaces
> >> would still use some counter-based vcpu identifiers internally, to avoid
> >> large, sparse structures, but I guess the advantage is that they don't
> >> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
> >> is already 32-bits, and is supposed to be an arbitrary identifier. That
> >> all looks good for converting to MPIDR.
> >>
> >
> > Correction. I understand that vcpu-id is "supposed" to be an arbitrary
> > identifier now, but it doesn't appear that all the assumptions that it's
> > a counter are gone yet... virt/kvm/kvm_main.c has
> >
> > static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
> > ...
> > if (id >= KVM_MAX_VCPUS)
> > return -EINVAL;
>
> I think the last time we talked about supporting "userspace
> determines MPIDR" the idea was to do it by allowing userspace to
> write to the MPIDR register with KVM_SET_ONE_REG. So you'd
> create a bunch of CPUs with vcpu-ids as usual, and then the
> MPIDRs would be set for them later as appropriate (or not
> at all, if userspace was an older qemu).
Yup, I recall that. I'm just expanding this discussion into that one.
If we wanted to single vcpu identifier type, and we wanted it to be
MPIDR, then I guess we'd want to pass it in to KVM_CREATE_VCPU too, at
which point we no longer need to set it later with KVM_SET_ONE_REG.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:44 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:44 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 04:29:03PM +0000, Peter Maydell wrote:
> On 11 January 2016 at 16:21, Andrew Jones <drjones@redhat.com> wrote:
> > On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
> >> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> >> > Are vcpu ids already exposed to userspace (beyond the stupid
> >> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> >> > format they have?
> >>
> >> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
> >> to MPIDR for that, and it would be a nice way to handle the "userspace
> >> determines MPIDR" work that I plan to do. Both KVM and its userspaces
> >> would still use some counter-based vcpu identifiers internally, to avoid
> >> large, sparse structures, but I guess the advantage is that they don't
> >> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
> >> is already 32-bits, and is supposed to be an arbitrary identifier. That
> >> all looks good for converting to MPIDR.
> >>
> >
> > Correction. I understand that vcpu-id is "supposed" to be an arbitrary
> > identifier now, but it doesn't appear that all the assumptions that it's
> > a counter are gone yet... virt/kvm/kvm_main.c has
> >
> > static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
> > ...
> > if (id >= KVM_MAX_VCPUS)
> > return -EINVAL;
>
> I think the last time we talked about supporting "userspace
> determines MPIDR" the idea was to do it by allowing userspace to
> write to the MPIDR register with KVM_SET_ONE_REG. So you'd
> create a bunch of CPUs with vcpu-ids as usual, and then the
> MPIDRs would be set for them later as appropriate (or not
> at all, if userspace was an older qemu).
Yup, I recall that. I'm just expanding this discussion into that one.
If we wanted to single vcpu identifier type, and we wanted it to be
MPIDR, then I guess we'd want to pass it in to KVM_CREATE_VCPU too, at
which point we no longer need to set it later with KVM_SET_ONE_REG.
Thanks,
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
2016-01-11 16:13 ` Peter Maydell
@ 2016-01-11 16:48 ` Andrew Jones
-1 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:48 UTC (permalink / raw)
To: Peter Maydell
Cc: Christoffer Dall, Marc Zyngier, Shannon Zhao, kvmarm, kvm-devel,
Will Deacon, Shannon Zhao, arm-mail-list
On Mon, Jan 11, 2016 at 04:13:12PM +0000, Peter Maydell wrote:
> On 11 January 2016 at 16:09, Andrew Jones <drjones@redhat.com> wrote:
> > I think the save/restore case is where I always flip to seeing it as a
> > bunch of separate per cpu devices. It would feel better to me to
> > save/restore the cpu-gic registers the same way we do all other cpu
> > registers.
>
> From QEMU's point of view this would be extremely awkward, which
> is one reason I'm happy with the GICv3 API we came up with
> and reviewed last year...
OK, I'll shut up about this. As I didn't speak then, I shall now forever
hold my peace :)
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
* [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device
@ 2016-01-11 16:48 ` Andrew Jones
0 siblings, 0 replies; 197+ messages in thread
From: Andrew Jones @ 2016-01-11 16:48 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 11, 2016 at 04:13:12PM +0000, Peter Maydell wrote:
> On 11 January 2016 at 16:09, Andrew Jones <drjones@redhat.com> wrote:
> > I think the save/restore case is where I always flip to seeing it as a
> > bunch of separate per cpu devices. It would feel better to me to
> > save/restore the cpu-gic registers the same way we do all other cpu
> > registers.
>
> From QEMU's point of view this would be extremely awkward, which
> is one reason I'm happy with the GICv3 API we came up with
> and reviewed last year...
OK, I'll shut up about this. As I didn't speak then, I shall now forever
hold my peace :)
drew
^ permalink raw reply [flat|nested] 197+ messages in thread
end of thread, other threads:[~2016-01-11 16:48 UTC | newest]
Thread overview: 197+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-22 8:07 [PATCH v8 00/20] KVM: ARM64: Add guest PMU support Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` [PATCH v8 01/20] ARM64: Move PMU register related defines to asm/pmu.h Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2016-01-07 10:20 ` Marc Zyngier
2016-01-07 10:20 ` Marc Zyngier
2015-12-22 8:07 ` [PATCH v8 02/20] KVM: ARM64: Define PMU data structure for each vcpu Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2016-01-07 10:21 ` Marc Zyngier
2016-01-07 10:21 ` Marc Zyngier
2016-01-07 19:07 ` Andrew Jones
2016-01-07 19:07 ` Andrew Jones
2015-12-22 8:07 ` [PATCH v8 03/20] KVM: ARM64: Add offset defines for PMU registers Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2016-01-07 10:23 ` Marc Zyngier
2016-01-07 10:23 ` Marc Zyngier
2015-12-22 8:07 ` [PATCH v8 04/20] KVM: ARM64: Add access handler for PMCR register Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2015-12-22 8:07 ` Shannon Zhao
2016-01-07 10:43 ` Marc Zyngier
2016-01-07 10:43 ` Marc Zyngier
2016-01-07 11:16 ` Shannon Zhao
2016-01-07 11:16 ` Shannon Zhao
2016-01-07 11:16 ` Shannon Zhao
2015-12-22 8:08 ` [PATCH v8 05/20] KVM: ARM64: Add access handler for PMSELR register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 10:43 ` Marc Zyngier
2016-01-07 10:43 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 06/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 10:44 ` Marc Zyngier
2016-01-07 10:44 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 07/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 10:55 ` Marc Zyngier
2016-01-07 10:55 ` Marc Zyngier
2016-01-07 13:48 ` Marc Zyngier
2016-01-07 13:48 ` Marc Zyngier
2016-01-07 14:00 ` Shannon Zhao
2016-01-07 14:00 ` Shannon Zhao
2016-01-07 14:00 ` Shannon Zhao
2015-12-22 8:08 ` [PATCH v8 08/20] KVM: ARM64: Add access handler for event typer register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:03 ` Marc Zyngier
2016-01-07 11:03 ` Marc Zyngier
2016-01-07 11:11 ` Shannon Zhao
2016-01-07 11:11 ` Shannon Zhao
2016-01-07 11:11 ` Shannon Zhao
2016-01-07 12:36 ` Shannon Zhao
2016-01-07 12:36 ` Shannon Zhao
2016-01-07 12:36 ` Shannon Zhao
2016-01-07 13:15 ` Marc Zyngier
2016-01-07 13:15 ` Marc Zyngier
2016-01-07 12:09 ` Shannon Zhao
2016-01-07 12:09 ` Shannon Zhao
2016-01-07 12:09 ` Shannon Zhao
2016-01-07 13:01 ` Marc Zyngier
2016-01-07 13:01 ` Marc Zyngier
2016-01-07 19:17 ` Andrew Jones
2016-01-07 19:17 ` Andrew Jones
2015-12-22 8:08 ` [PATCH v8 09/20] KVM: ARM64: Add access handler for event counter register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:06 ` Marc Zyngier
2016-01-07 11:06 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 10/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:09 ` Marc Zyngier
2016-01-07 11:09 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 11/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:13 ` Marc Zyngier
2016-01-07 11:13 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 12/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:14 ` Marc Zyngier
2016-01-07 11:14 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 13/20] KVM: ARM64: Add access handler for PMSWINC register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:29 ` Marc Zyngier
2016-01-07 11:29 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 14/20] KVM: ARM64: Add helper to handle PMCR register bits Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 11:59 ` Marc Zyngier
2016-01-07 11:59 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 15/20] KVM: ARM64: Add a helper to forward trap to guest EL1 Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` [PATCH v8 16/20] KVM: ARM64: Add access handler for PMUSERENR register Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 10:14 ` Marc Zyngier
2016-01-07 10:14 ` Marc Zyngier
2016-01-07 11:15 ` Shannon Zhao
2016-01-07 11:15 ` Shannon Zhao
2016-01-07 11:15 ` Shannon Zhao
2015-12-22 8:08 ` [PATCH v8 17/20] KVM: ARM64: Add PMU overflow interrupt routing Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 13:28 ` Marc Zyngier
2016-01-07 13:28 ` Marc Zyngier
2016-01-07 13:28 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 18/20] KVM: ARM64: Reset PMU state when resetting vcpu Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 13:39 ` Marc Zyngier
2016-01-07 13:39 ` Marc Zyngier
2016-01-07 13:39 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 19/20] KVM: ARM64: Free perf event of PMU when destroying vcpu Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 13:51 ` Marc Zyngier
2016-01-07 13:51 ` Marc Zyngier
2015-12-22 8:08 ` [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2015-12-22 8:08 ` Shannon Zhao
2016-01-07 13:56 ` Marc Zyngier
2016-01-07 13:56 ` Marc Zyngier
2016-01-07 14:35 ` Shannon Zhao
2016-01-07 14:35 ` Shannon Zhao
2016-01-07 14:35 ` Shannon Zhao
2016-01-07 14:36 ` Peter Maydell
2016-01-07 14:36 ` Peter Maydell
2016-01-07 14:49 ` Shannon Zhao
2016-01-07 14:49 ` Shannon Zhao
2016-01-07 14:56 ` Peter Maydell
2016-01-07 14:56 ` Peter Maydell
2016-01-07 20:36 ` Andrew Jones
2016-01-07 20:36 ` Andrew Jones
2016-01-09 12:29 ` Christoffer Dall
2016-01-09 12:29 ` Christoffer Dall
2016-01-09 15:03 ` Marc Zyngier
2016-01-09 15:03 ` Marc Zyngier
2016-01-11 8:45 ` Shannon Zhao
2016-01-11 8:45 ` Shannon Zhao
2016-01-11 8:59 ` Marc Zyngier
2016-01-11 8:59 ` Marc Zyngier
2016-01-11 11:52 ` Andrew Jones
2016-01-11 11:52 ` Andrew Jones
2016-01-11 12:03 ` Shannon Zhao
2016-01-11 12:03 ` Shannon Zhao
2016-01-11 14:07 ` Andrew Jones
2016-01-11 14:07 ` Andrew Jones
2016-01-11 15:09 ` Christoffer Dall
2016-01-11 15:09 ` Christoffer Dall
2016-01-11 16:09 ` Andrew Jones
2016-01-11 16:09 ` Andrew Jones
2016-01-11 16:13 ` Peter Maydell
2016-01-11 16:13 ` Peter Maydell
2016-01-11 16:48 ` Andrew Jones
2016-01-11 16:48 ` Andrew Jones
2016-01-11 16:21 ` Andrew Jones
2016-01-11 16:21 ` Andrew Jones
2016-01-11 16:29 ` Peter Maydell
2016-01-11 16:29 ` Peter Maydell
2016-01-11 16:44 ` Andrew Jones
2016-01-11 16:44 ` Andrew Jones
2016-01-08 3:06 ` Shannon Zhao
2016-01-08 3:06 ` Shannon Zhao
2016-01-08 10:24 ` Peter Maydell
2016-01-08 10:24 ` Peter Maydell
2016-01-08 12:15 ` Shannon Zhao
2016-01-08 12:15 ` Shannon Zhao
2016-01-08 12:56 ` Peter Maydell
2016-01-08 12:56 ` Peter Maydell
2016-01-08 13:31 ` Shannon Zhao
2016-01-08 13:31 ` Shannon Zhao
2016-01-07 20:18 ` Andrew Jones
2016-01-07 20:18 ` Andrew Jones
2016-01-08 2:53 ` Shannon Zhao
2016-01-08 2:53 ` Shannon Zhao
2016-01-08 2:53 ` Shannon Zhao
2016-01-08 11:22 ` Andrew Jones
2016-01-08 11:22 ` Andrew Jones
2016-01-08 15:20 ` Andrew Jones
2016-01-08 15:20 ` Andrew Jones
2016-01-08 15:59 ` Andrew Jones
2016-01-08 15:59 ` Andrew Jones
2016-01-07 14:10 ` [PATCH v8 00/20] KVM: ARM64: Add guest PMU support Marc Zyngier
2016-01-07 14:10 ` Marc Zyngier
2016-01-07 14:12 ` Will Deacon
2016-01-07 14:12 ` Will Deacon
2016-01-07 14:21 ` Marc Zyngier
2016-01-07 14:21 ` Marc Zyngier
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.