More fully implement ARM PMUv3
v3 cover More fully implement ARM PMUv3
The ARM PMU implementation currently contains a basic cycle counter, but it is often useful to gather counts of other events and filter them based on execution mode. These patches flesh out the implementations of various PMU registers including PM[X]EVCNTR and PM[X]EVTYPER, add a struct definition to represent arbitrary counter types, implement mode filtering, and add instruction, cycle, and software increment events.
I aim to eventually add raising interrupts on counter overflow, but that is not covered by this patchset. I think I have a reasonable grasp of the mechanics of *how* to raise them, but am curious if anyone has thoughts on how to determine *when* to raise them - we don't want to call into PMU code every time an instruction is executed to check if any instruction counters have overflowed, etc. The main candidate I've seen for doing this so far would be to set up a QEMUTimer, but I haven't fully explored it. Does that seem plausible? Any other/better ideas?
Changes from v2:
* Many minor fixups (splitting patches, style/comment fixes, etc.)
* Save off current cycle count during operations which may change whether a counter is enabled, ensuring time isn't lost (update to patch 5)
* Added the ability to have more than one el_change_hook, added hooks before EL changes (patches 7-9)
* Added proper handling of can_do_io during code-gen before and after the el_change_hooks (patch 8)
* Split off PMOVSSET register definitions so they are only enabled for v7ve+ (added patch 15, update to 16)
Thanks for any feedback,
Aaron
Aaron Lindsay (22):
target/arm: A53: Initialize PMCEID[01]
target/arm: A15 PMCEID0 initialization style nit target/arm: Check PMCNTEN for whether PMCCNTR is enabled target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0 target/arm: Reorganize PMCCNTR read, write, sync target/arm: Mask PMU register writes based on PMCR_EL0.N target/arm: Fetch GICv3 state directly from CPUARMState target/arm: Support multiple EL change hooks
target/arm: Add pre-EL change hooks
target/arm: Allow EL change hooks to do IO
target/arm: Fix bitmask for PMCCFILTR writes
target/arm: Filter cycle counter based on PMCCFILTR_EL0 target/arm: Allow AArch32 access for PMCCFILTR target/arm: Make PMOVSCLR 64 bits wide
target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions target/arm: Implement PMOVSSET
target/arm: Split arm_ccnt_enabled into generic pmu_counter_enabled target/arm: Add array for supported PMU events, generate PMCEID[01] target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER target/arm: PMU: Add instruction and cycle events target/arm: PMU: Set PMCR.N to 4
target/arm: Implement PMSWINC
hw/intc/arm_gicv3_cpuif.c | 10 +- target/arm/cpu.c | 40 ++- target/arm/cpu.h | 102 +++++--- target/arm/cpu64.c | 2 + target/arm/helper.c | 616 ++++++++++++++++++++++++++++++++++++++------- target/arm/internals.h | 14 +- target/arm/op_helper.c | 8 + target/arm/translate-a64.c | 2 + target/arm/translate.c | 4 + 9 files changed, 651 insertions(+), 147 deletions(-)
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 1/22 target/arm: A53: Initialize PMCEID[01]
A53 advertises ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.
--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)
target/arm/cpu64.c +2 -0
@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [Qemu-arm] [PATCH v3 01/22] target/arm: A53: Initialize PMCEID[01]
Hi Aaron,
Quoted 14 lines · Aaron Lindsay
A53 advertises
ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)target/arm/cpu64.c +0
-0
target/arm/cpu64.c static void aarch64_a53_initfn(Object *obj) · line 208
Quoted 8 lines
target/arm/cpu64.c +2
-0@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;
Maybe we can move this at a single place in arm_cpu_post_init():
if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) {
cpu->pmceid0 = 0x00000000;
cpu->pmceid1 = 0x00000000;
}Regards,
Phil.
Re: [Qemu-arm] [PATCH v3 01/22] target/arm: A53: Initialize PMCEID[01]
Quoted 11 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 8 lines · Aaron Lindsay
A53 advertises
ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)
Quoted 16 lines
Quoted 6 lines
target/arm/cpu64.c +0
-0target/arm/cpu64.c static void aarch64_a53_initfn(Object *obj) · line 208
Quoted 8 lines
target/arm/cpu64.c +2
-0@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;Maybe we can move this at a single place in
arm_cpu_post_init():
Err, arm_cpu_reset() :)
Quoted 10 lines
if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) { cpu->pmceid0 = 0x00000000; cpu->pmceid1 = 0x00000000; }Regards,
Phil.
Re: [Qemu-arm] [PATCH v3 01/22] target/arm: A53: Initialize PMCEID[01]
In reply to Philippe Mathieu-DaudéQuoted 28 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 14 lines · Aaron Lindsay
A53 advertises
ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)target/arm/cpu64.c +0
-0target/arm/cpu64.c static void aarch64_a53_initfn(Object *obj) · line 208
Quoted 8 lines
target/arm/cpu64.c +2
-0@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;Maybe we can move this at a single place in
arm_cpu_post_init():
Quoted 4 lines
if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) {
cpu->pmceid0 = 0x00000000;
cpu->pmceid1 = 0x00000000;
}I like consolidating the initialization - though I think it can go in arm_cpu_realizefn() with the preexisting PMU-related id_aa64dfr0 initialization since it is constant once you've chosen a type of processor. One of the other patches in this set actually already adds some PMCEID initialization there based on PMCR.N.
-Aaron
Quoted 4 lines
Regards,
Phil.
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 01/22] target/arm: A53: Initialize PMCEID[01]
Quoted 34 lines · Aaron Lindsay
Quoted 28 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 14 lines · Aaron Lindsay
A53 advertises
ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)target/arm/cpu64.c +0
-0target/arm/cpu64.c static void aarch64_a53_initfn(Object *obj) · line 208
Quoted 8 lines
target/arm/cpu64.c +2
-0@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;Maybe we can move this at a single place in
arm_cpu_post_init():Quoted 4 lines
if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) { cpu->pmceid0 = 0x00000000; cpu->pmceid1 = 0x00000000; }
Quoted 5 lines
I like consolidating the initialization - though I think it can go in
arm_cpu_realizefn()with the preexisting PMU-relatedid_aa64dfr0initialization since it is constant once you've chosen a type of processor. One of the other patches in this set actually already adds some PMCEID initialization there based on PMCR.N.
Indeed, arm_cpu_realizefn() is a good place.
Re: [Qemu-arm] [PATCH v3 01/22] target/arm: A53: Initialize PMCEID[01]
Quoted 35 lines · Philippe Mathieu-Daudé
Quoted 34 lines · Aaron Lindsay
Quoted 32 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 14 lines · Aaron Lindsay
A53 advertises
ARM_FEATURE_PMU, but wasn't initializing pmceid[01]. pmceid[01] are already being initialized to zero for both A15 and A57.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu64.c | 2 ++ 1 file changed, 2 insertions(+)target/arm/cpu64.c +0
-0target/arm/cpu64.c static void aarch64_a53_initfn(Object *obj) · line 208
Quoted 8 lines
target/arm/cpu64.c +2
-0@@ -201,6 +201,8 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar5 =0x00011121 ; cpu->id_aa64pfr0 =0x00002222 ; cpu->id_aa64dfr0 =0x10305106 ; + cpu->pmceid0 =0x00000000 ; + cpu->pmceid1 =0x00000000 ; cpu->id_aa64isar0 =0x00011120 ; cpu->id_aa64mmfr0 =0x00001122 ;/* 40 bit physical addr */ cpu->dbgdidr =0x3516d000 ;Maybe we can move this at a single place in
arm_cpu_post_init():if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) { cpu->pmceid0 = 0x00000000; cpu->pmceid1 = 0x00000000; }
Quoted 7 lines
Quoted 5 lines
I like consolidating the initialization - though I think it can go in
arm_cpu_realizefn()with the preexisting PMU-relatedid_aa64dfr0initialization since it is constant once you've chosen a type of processor. One of the other patches in this set actually already adds some PMCEID initialization there based on PMCR.N.Indeed,
arm_cpu_realizefn()is a good place.
I've consolidated the pmceid[01] initialization into arm_cpu_realizefn() for v4.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 2/22 target/arm: A15 PMCEID0 initialization style nit
In reply to Aaron Lindsay--- target/arm/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
target/arm/cpu.c +1 -1
@@ -1524,7 +1524,7 @@ static void cortex_a15_initfn(Object *obj) cpu->id_pfr0 =0x00001131 ; cpu->id_pfr1 =0x00011011 ; cpu->id_dfr0 =0x02010555 ; - cpu->pmceid0 =0x0000000 ; + cpu->pmceid0 =0x00000000 ; cpu->pmceid1 =0x00000000 ; cpu->id_afr0 =0x00000000 ; cpu->id_mmfr0 =0x10201105 ;
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 02/22] target/arm: A15 PMCEID0 initialization style nit
Quoted 10 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/cpu.c +0
-0
target/arm/cpu.c static void cortex_a15_initfn(Object *obj) · line 1530
Quoted 8 lines
target/arm/cpu.c +1
-1@@ -1524,7 +1524,7 @@ static void cortex_a15_initfn(Object *obj) cpu->id_pfr0 =0x00001131 ; cpu->id_pfr1 =0x00011011 ; cpu->id_dfr0 =0x02010555 ; - cpu->pmceid0 =0x0000000 ; + cpu->pmceid0 =0x00000000 ; cpu->pmceid1 =0x00000000 ; cpu->id_afr0 =0x00000000 ; cpu->id_mmfr0 =0x10201105 ;
thanks
-- PMM
PATCH v3 3/22 target/arm: Check PMCNTEN for whether PMCCNTR is enabled
In reply to Aaron Lindsay--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
target/arm/helper.c +1 -1
@@ -994,7 +994,7 @@ static inline bool arm_ccnt_enabled(CPUARMState *env) {/* This does not support checking PMCCFILTR_EL0 register */ -if (!(env->cp15.c9_pmcr &PMCRE )) { +if (!(env->cp15.c9_pmcr &PMCRE ) || !(env->cp15.c9_pmcnten & (1 <<31 ))) {return false; }
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 4/22 target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0
In reply to Aaron LindsayThey share the same underlying state
--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
target/arm/helper.c +1 -1
@@ -1318,7 +1318,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmselr), .writefn = pmselr_write, .raw_writefn = raw_write, }, { .name = "PMCCNTR", .cp = 15, .crn = 9, .crm = 13, .opc1 = 0, .opc2 = 0, - .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_IO, + .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_ALIAS | ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write32, .accessfn = pmreg_access_ccntr }, { .name = "PMCCNTR_EL0", .state = ARM_CP_STATE_AA64,
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 04/22] target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0
Quoted 12 lines · Aaron Lindsay
They share the same underlying state
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/helper.c +0
-0
target/arm/helper.c static const ARMCPRegInfo v7_cp_reginfo[] = {
Quoted 9 lines
target/arm/helper.c +1
-2@@ -1318,7 +1318,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmselr), .writefn = pmselr_write, .raw_writefn = raw_write, }, { .name = "PMCCNTR", .cp = 15, .crn = 9, .crm = 13, .opc1 = 0, .opc2 = 0, - .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_IO, + .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_ALIAS | ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write32, .accessfn = pmreg_access_ccntr }, { .name = "PMCCNTR_EL0", .state = ARM_CP_STATE_AA64, --
Does this fix an observed bug (presumably migration related), or is it just something you saw in code inspection ? Worth noting in the commit message if the former.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 04/22] target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0
Quoted 18 lines · Peter Maydell
Quoted 17 lines · Aaron Lindsay
They share the same underlying state
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/helper.c +1
-1@@ -1318,7 +1318,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmselr), .writefn = pmselr_write, .raw_writefn = raw_write, }, { .name = "PMCCNTR", .cp = 15, .crn = 9, .crm = 13, .opc1 = 0, .opc2 = 0, - .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_IO, + .access = PL0_RW, .resetvalue = 0, .type = ARM_CP_ALIAS | ARM_CP_IO,
Quoted 8 lines
target/arm/helper.c static const ARMCPRegInfo v7_cp_reginfo[] = {
Quoted 4 lines
target/arm/helper.c +0
-1.readfn = pmccntr_read, .writefn = pmccntr_write32, .accessfn = pmreg_access_ccntr }, { .name = "PMCCNTR_EL0", .state = ARM_CP_STATE_AA64, --Does this fix an observed bug (presumably migration related), or is it just something you saw in code inspection ? Worth noting in the commit message if the former.
Purely code inspection. I forget now, but I think I found it after chasing down some other register issue in the vicinity and noticed this while digging around.
-Aaron
Quoted 4 lines
Reviewed-by Peter Maydell <[email protected]>thanks
-- PMM
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 5/22 target/arm: Reorganize PMCCNTR read, write, sync
In reply to Aaron Lindsaypmccntr_read and pmccntr_write contained duplicate code that was already being handled by pmccntr_sync. Split pmccntr_sync into pmccntr_op_start and pmccntr_op_finish, passing the clock value between the two, to avoid losing time between the two calls.
--- target/arm/helper.c | 101 +++++++++++++++++++++++++++++----------------------- 1 file changed, 56 insertions(+), 45 deletions(-)
target/arm/helper.c +56 -45
@@ -1000,28 +1000,58 @@ static inline bool arm_ccnt_enabled(CPUARMState *env)return true; } - -void pmccntr_sync (CPUARMState *env) +/* +* Ensure c15_ccnt is the guest-visible count so that operations such as +* enabling/disabling the counter or filtering, modifying the count itself, +* etc. can be done logically. This is essentially a no-op if the counter is +* not enabled at the time of the call. +* +* The current cycle count is returned so that it can be passed into the paired +* pmccntr_op_finish() call which must follow each call to pmccntr_op_start(). +*/ +uint64_t pmccntr_op_start (CPUARMState *env) { -uint64_t temp_ticks; - - temp_ticks =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), +uint64_t cycles =0 ; +#ifndef CONFIG_USER_ONLY + cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ),ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); +#endif + +if (arm_ccnt_enabled (env)) { -if (env->cp15.c9_pmcr &PMCRD ) { -/* Increment once every 64 processor clock cycles */ - temp_ticks /=64 ; +uint64_t eff_cycles = cycles; +if (env->cp15.c9_pmcr &PMCRD ) { +/* Increment once every 64 processor clock cycles */ + eff_cycles /=64 ; + } + + env->cp15.c15_ccnt = eff_cycles - env->cp15.c15_ccnt; } +return cycles; +} +/* +* If enabled, convert c15_ccnt back into the delta between the clock and the +* guest-visible count. A call to pmccntr_op_finish should follow every call to +* pmccntr_op_start. +*/ +void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) +{if (arm_ccnt_enabled (env)) { - env->cp15.c15_ccnt = temp_ticks - env->cp15.c15_ccnt; + +if (env->cp15.c9_pmcr &PMCRD ) { +/* Increment once every 64 processor clock cycles */ + prev_cycles /=64 ; + } + + env->cp15.c15_ccnt = prev_cycles - env->cp15.c15_ccnt; } }static void pmcr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { -pmccntr_sync (env); +uint64_t saved_cycles =pmccntr_op_start (env);if (value &PMCRC ) {/* The counter has been reset */
@@ -1032,26 +1062,16 @@ static void pmcr_write(CPUARMState *env, const ARMCPRegInfo *ri, env->cp15.c9_pmcr &= ~0x39 ; env->cp15.c9_pmcr |= (value &0x39 ); -pmccntr_sync (env); +pmccntr_op_finish (env, saved_cycles); }static uint64_t pmccntr_read (CPUARMState *env,const ARMCPRegInfo *ri) { -uint64_t total_ticks; - -if (!arm_ccnt_enabled (env)) { -/* Counter is disabled, do not change value */ -return env->cp15.c15_ccnt; - } - - total_ticks =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); - -if (env->cp15.c9_pmcr &PMCRD ) { -/* Increment once every 64 processor clock cycles */ - total_ticks /=64 ; - } -return total_ticks - env->cp15.c15_ccnt; +uint64_t ret; +uint64_t saved_cycles =pmccntr_op_start (env); + ret = env->cp15.c15_ccnt; +pmccntr_op_finish (env, saved_cycles); +return ret; } static void pmselr_write(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -1068,22 +1088,9 @@ static void pmselr_write(CPUARMState *env, const ARMCPRegInfo *ri,static void pmccntr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { -uint64_t total_ticks; - -if (!arm_ccnt_enabled (env)) { -/* Counter is disabled, set the absolute value */ - env->cp15.c15_ccnt = value; -return ; - } - - total_ticks =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); - -if (env->cp15.c9_pmcr &PMCRD ) { -/* Increment once every 64 processor clock cycles */ - total_ticks /=64 ; - } - env->cp15.c15_ccnt = total_ticks - value; +uint64_t saved_cycles =pmccntr_op_start (env); + env->cp15.c15_ccnt = value; +pmccntr_op_finish (env, saved_cycles); } static void pmccntr_write32(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -1096,7 +1103,11 @@ static void pmccntr_write32(CPUARMState *env, const ARMCPRegInfo *ri,#else /* CONFIG_USER_ONLY */ -void pmccntr_sync (CPUARMState *env) +uint64_t pmccntr_op_start (CPUARMState *env) +{ +} + +void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) { }
@@ -1105,9 +1116,9 @@ void pmccntr_sync(CPUARMState *env)static void pmccfiltr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { -pmccntr_sync (env); +uint64_t saved_cycles =pmccntr_op_start (env); env->cp15.pmccfiltr_el0 = value &0x7E000000 ; -pmccntr_sync (env); +pmccntr_op_finish (env, saved_cycles); } static void pmcntenset_write(CPUARMState *env, const ARMCPRegInfo *ri,
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 05/22] target/arm: Reorganize PMCCNTR read, write, sync
Quoted 15 lines · Aaron Lindsay
pmccntr_readandpmccntr_writecontained duplicate code that was already being handled bypmccntr_sync. Splitpmccntr_syncintopmccntr_op_startandpmccntr_op_finish, passing the clock value between the two, to avoid losing time between the two calls.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 101 +++++++++++++++++++++++++++++----------------------- 1 file changed, 56 insertions(+), 45 deletions(-)target/arm/helper.c +0
-0
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1004
Quoted 5 lines
target/arm/helper.c +0
-2@@ -1000,28 +1000,58 @@ static inline bool arm_ccnt_enabled(CPUARMState *env)return true; } - -void pmccntr_sync (CPUARMState *env)
If you configure your git to use the 'histogram' diff algorithm ("git config --global diff.algorithm histogram", or edit ~/.gitconfig equivalently), does it make git format-patch make less of a mess of this commit ?
Quoted 9 lines
target/arm/helper.c +9
-0+/* +* Ensure c15_ccnt is the guest-visible count so that operations such as +* enabling/disabling the counter or filtering, modifying the count itself, +* etc. can be done logically. This is essentially a no-op if the counter is +* not enabled at the time of the call. +* +* The current cycle count is returned so that it can be passed into the paired +* pmccntr_op_finish() call which must follow each call to pmccntr_op_start(). +*/
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1018
Quoted 10 lines
target/arm/helper.c +5
-3+uint64_t pmccntr_op_start (CPUARMState *env) { -uint64_t temp_ticks; - - temp_ticks =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), +uint64_t cycles =0 ; +#ifndef CONFIG_USER_ONLY + cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ),ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); +#endif
Is this ifdef necessary? You have a do-nothing version of pmccntr_op_start() for CONFIG_USER_ONLY later on, so presumably this one is already inside a suitable ifndef.
Otherwise
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 05/22] target/arm: Reorganize PMCCNTR read, write, sync
Quoted 17 lines · Peter Maydell
Quoted 16 lines · Aaron Lindsay
pmccntr_readandpmccntr_writecontained duplicate code that was already being handled bypmccntr_sync. Splitpmccntr_syncintopmccntr_op_startandpmccntr_op_finish, passing the clock value between the two, to avoid losing time between the two calls.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 101 +++++++++++++++++++++++++++++----------------------- 1 file changed, 56 insertions(+), 45 deletions(-)target/arm/helper.c +0
-0@@ -1000,28 +1000,58 @@ static inline bool arm_ccnt_enabled(CPUARMState *env)
Quoted 9 lines
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1004
Quoted 4 lines
target/arm/helper.c +0
-2return true; } - -void pmccntr_sync (CPUARMState *env)If you configure your git to use the 'histogram' diff algorithm ("git config --global diff.algorithm histogram", or edit ~/.gitconfig equivalently), does it make git format-patch make less of a mess of this commit ?
No, it doesn't seem to make much of a difference.
Quoted 15 lines
Quoted 15 lines
target/arm/helper.c +11
-3+/* +* Ensure c15_ccnt is the guest-visible count so that operations such as +* enabling/disabling the counter or filtering, modifying the count itself, +* etc. can be done logically. This is essentially a no-op if the counter is +* not enabled at the time of the call. +* +* The current cycle count is returned so that it can be passed into the paired +* pmccntr_op_finish() call which must follow each call to pmccntr_op_start(). +*/ +uint64_t pmccntr_op_start (CPUARMState *env) { -uint64_t temp_ticks; - - temp_ticks = muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), +uint64_t cycles =0 ;
Quoted 8 lines
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1018
Quoted 4 lines
target/arm/helper.c +3
-0+#ifndef CONFIG_USER_ONLY + cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ),ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); +#endif Is this ifdef necessary? You have a do-nothing version of
pmccntr_op_start()forCONFIG_USER_ONLYlater on, so presumably this one is already inside a suitable ifndef.
You're right that it is unnecessary as of this patch. A later patch removes the surrounding #ifndef CONFIG_USER_ONLY when it is no longer necessary at that level. It would be cleaner to add the #ifndef with smaller scope at the same time - I'll make that change.
Quoted 3 lines
Otherwise
Reviewed-by Peter Maydell <[email protected]>
Because I've modified how pmccntr_op_start/finish keep track of the cycles so that they store the counter values differently for v4, I don't feel comfortable adding your Reviewed-by. I apologize for the churn.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 6/22 target/arm: Mask PMU register writes based on PMCR_EL0.N
In reply to Aaron LindsayThis is in preparation for enabling counters other than PMCCNTR
--- target/arm/helper.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-)
target/arm/helper.c +15 -9
@@ -52,11 +52,6 @@ typedef struct V8M_SAttributes {static void v8m_security_lookup (CPUARMState *env,uint32_t address,MMUAccessType access_type,ARMMMUIdx mmu_idx,V8M_SAttributes *sattrs); - -/* Definitions for the PMCCNTR and PMCR registers */ -#define PMCRD 0x8 -#define PMCRC 0x4 -#define PMCRE 0x1#endif static int vfp_gdb_get_reg (CPUARMState *env,uint8_t *buf,int reg)
@@ -906,6 +901,17 @@ static const ARMCPRegInfo v6_cp_reginfo[] = { REGINFO_SENTINEL }; +/* Definitions for the PMU registers */ +#define PMCRN_MASK 0xf800 +#define PMCRN_SHIFT 11 +#define PMCRD 0x8 +#define PMCRC 0x4 +#define PMCRE 0x1 + +#define PMU_NUM_COUNTERS (env) ((env->cp15.c9_pmcr & PMCRN_MASK) >> PMCRN_SHIFT) +/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ +#define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1)) +static CPAccessResult pmreg_access (CPUARMState *env,const ARMCPRegInfo *ri,bool isread) {
@@ -1124,14 +1130,14 @@ static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri,static void pmcntenset_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { - value &= (1 <<31 ); + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pmcnten |= value; }static void pmcntenclr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { - value &= (1 <<31 ); + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pmcnten &= ~value; }
@@ -1179,14 +1185,14 @@ static void pmintenset_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) {/* We have no event counters so only the C bit can be changed */ - value &= (1 <<31 ); + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pminten |= value; }static void pmintenclr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { - value &= (1 <<31 ); + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pminten &= ~value; }
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 06/22] target/arm: Mask PMU register writes based on PMCR_EL0.N
Quoted 27 lines · Aaron Lindsay
This is in preparation for enabling counters other than PMCCNTR
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-)target/arm/helper.c +0
-5@@ -52,11 +52,6 @@ typedef struct V8M_SAttributes {static void v8m_security_lookup (CPUARMState *env,uint32_t address,MMUAccessType access_type,ARMMMUIdx mmu_idx,V8M_SAttributes *sattrs); - -/* Definitions for the PMCCNTR and PMCR registers */ -#define PMCRD 0x8 -#define PMCRC 0x4 -#define PMCRE 0x1#endif static int vfp_gdb_get_reg (CPUARMState *env,uint8_t *buf,int reg)@@ -906,6 +901,17 @@ static const ARMCPRegInfo v6_cp_reginfo[] = { REGINFO_SENTINEL };
target/arm/helper.c static const ARMCPRegInfo v6_cp_reginfo[] = { · line 913
Quoted 10 lines
target/arm/helper.c +10
-0+/* Definitions for the PMU registers */ +#define PMCRN_MASK 0xf800 +#define PMCRN_SHIFT 11 +#define PMCRD 0x8 +#define PMCRC 0x4 +#define PMCRE 0x1 + +#define PMU_NUM_COUNTERS (env) ((env->cp15.c9_pmcr & PMCRN_MASK) >> PMCRN_SHIFT) +/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ +#define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1))
These would be better as inline functions I think.
Otherwise
thanks
-- PMM
PATCH v3 7/22 target/arm: Fetch GICv3 state directly from CPUARMState
In reply to Aaron LindsayThis eliminates the need for fetching it from el_change_hook_opaque, and allows for supporting multiple el_change_hooks without having to hack something together to find the registered opaque belonging to GICv3.
--- hw/intc/arm_gicv3_cpuif.c | 10 ++-------- target/arm/cpu.h | 10 ---------- 2 files changed, 2 insertions(+), 18 deletions(-)
hw/intc/arm_gicv3_cpuif.c +2 -8
@@ -29,11 +29,7 @@ void gicv3_set_gicv3state(CPUState *cpu, GICv3CPUState *s)static GICv3CPUState *icc_cs_from_env (CPUARMState *env) { -/* Given the CPU, find the right GICv3CPUState struct. -* Since we registered the CPU interface with the EL change hook as -* the opaque pointer, we can just directly get from the CPU to it. -*/ -return arm_get_el_change_hook_opaque (arm_env_get_cpu (env)); +return env->gicv3state; }static bool gicv3_use_ns_bank (CPUARMState *env)
@@ -2615,9 +2611,7 @@ void gicv3_init_cpuif(GICv3State *s)* it might be with code translated by CPU 0 but run by CPU 1, in * which case we'd get the wrong value. * So instead we define the regs with no ri->opaque info, and -* get back to the GICv3CPUState from the ARMCPU by reading back -* the opaque pointer from the el_change_hook, which we're going -* to need to register anyway. +* get back to the GICv3CPUState from the CPUARMState. */ define_arm_cp_regs (cpu, gicv3_cpuif_reginfo); if (arm_feature(&cpu->env, ARM_FEATURE_EL2)
target/arm/cpu.h +0 -10
@@ -2904,16 +2904,6 @@ void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHook *hook, void *opaque);/** -* arm_get_el_change_hook_opaque: -* Return the opaque data that will be used by the el_change_hook -* for this CPU. -*/ -static inline void *arm_get_el_change_hook_opaque (ARMCPU *cpu) -{ -return cpu->el_change_hook_opaque; -} - -/** * aa32_vfp_dreg: * Return a pointer to the Dn register within env in 32-bit mode. */
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 07/22] target/arm: Fetch GICv3 state directly from CPUARMState
Quoted 9 lines · Aaron Lindsay
This eliminates the need for fetching it from
el_change_hook_opaque, and allows for supporting multipleel_change_hookswithout having to hack something together to find the registered opaque belonging to GICv3.Signed-off-by Aaron Lindsay <[email protected]>--- hw/intc/arm_gicv3_cpuif.c | 10 ++-------- target/arm/cpu.h | 10 ---------- 2 files changed, 2 insertions(+), 18 deletions(-)
I'm not wonderfully happy about this, because the original aim here was to try to keep the GICv3 device end reasonably decoupled from the CPU proper. On the other hand since d3a3e529626fb we've had this pointer because we ended up needing it in the KVM reset codepath, so we might as well use it here too. Maybe one day I'll come back to this and clean it up.
thanks
-- PMM
PATCH v3 8/22 target/arm: Support multiple EL change hooks
In reply to Aaron Lindsay--- target/arm/cpu.c | 15 ++++++++++----- target/arm/cpu.h | 23 ++++++++++++----------- target/arm/internals.h | 7 ++++--- 3 files changed, 26 insertions(+), 19 deletions(-)
target/arm/cpu.c +10 -5
@@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); } -void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) { -/* We currently only support registering a single hook function */ -assert (!cpu->el_change_hook); - cpu->el_change_hook = hook; - cpu->el_change_hook_opaque = opaque; +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry)); + + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->el_change_hooks, entry, node); }static void cp_reg_reset (gpointer key,gpointer value,gpointer opaque)
@@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->el_change_hooks); +/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 );
target/arm/cpu.h +12 -11
@@ -633,11 +633,17 @@ typedef struct CPUARMState {/** * ARMELChangeHook: -* type of a function which can be registered via arm_register_el_change_hook() -* to get callbacks when the CPU changes its exception level or mode. +* Support registering functions with ARMELChangeHookFn's signature via +* arm_register_el_change_hook() to get callbacks when the CPU changes its +* exception level or mode. */ -typedef void ARMELChangeHook (ARMCPU *cpu,void *opaque); - +typedef void ARMELChangeHookFn (ARMCPU *cpu,void *opaque); +typedef struct ARMELChangeHook ARMELChangeHook ; +struct ARMELChangeHook { +ARMELChangeHookFn *hook; +void *opaque; +QLIST_ENTRY (ARMELChangeHook) node; +};/* These values map onto the return values for * QEMU_PSCI_0_2_FN_AFFINITY_INFO */
@@ -826,8 +832,7 @@ struct ARMCPU {*/ bool cfgend; -ARMELChangeHook *el_change_hook; -void *el_change_hook_opaque; + QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */
@@ -2895,12 +2900,8 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)* CPU changes exception level or mode. The hook function will be * passed a pointer to the ARMCPU and the opaque data pointer passed * to this function when the hook was registered. -* -* Note that we currently only support registering a single hook function, -* and will assert if this function is called twice. -* This facility is intended for the use of the GICv3 emulation. */ -void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque);/**
target/arm/internals.h +4 -3
@@ -727,11 +727,12 @@ void arm_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, int mmu_idx, MemTxAttrs attrs, MemTxResult response, uintptr_t retaddr); -/* Call the EL change hook if one has been registered */ +/* Call any registered EL change hooks */ static inline void arm_call_el_change_hook (ARMCPU *cpu) { -if (cpu->el_change_hook) { - cpu->el_change_hook (cpu, cpu->el_change_hook_opaque); +ARMELChangeHook *hook, *next; + QLIST_FOREACH_SAFE(hook, &cpu->el_change_hooks, node, next) { + hook->hook (cpu, hook->opaque); } }
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [Qemu-arm] [PATCH v3 08/22] target/arm: Support multiple EL change hooks
Quoted 15 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 15 ++++++++++----- target/arm/cpu.h | 23 ++++++++++++----------- target/arm/internals.h | 7 ++++--- 3 files changed, 26 insertions(+), 19 deletions(-)target/arm/cpu.c +0
-0@@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); }
target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 10 lines
target/arm/cpu.c +3
-5-void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) { -/* We currently only support registering a single hook function */ -assert (!cpu->el_change_hook); - cpu->el_change_hook = hook; - cpu->el_change_hook_opaque = opaque; +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));
imho g_malloc() is enough.
Quoted 9 lines
target/arm/cpu.c +5
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->el_change_hooks, entry, node); }static void cp_reg_reset (gpointer key,gpointer value,gpointer opaque)
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 751
Quoted 5 lines
target/arm/cpu.c +2
-0@@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->el_change_hooks); +
You missed to fill arm_cpu_unrealizefn() with:
QLIST_FOREACH(...) {
QLIST_REMOVE(...);
g_free(...);
}Quoted 74 lines
target/arm/cpu.c +0
-0/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 );target/arm/cpu.h +12
-11@@ -633,11 +633,17 @@ typedef struct CPUARMState {/** * ARMELChangeHook: -* type of a function which can be registered via arm_register_el_change_hook() -* to get callbacks when the CPU changes its exception level or mode. +* Support registering functions with ARMELChangeHookFn's signature via +* arm_register_el_change_hook() to get callbacks when the CPU changes its +* exception level or mode. */ -typedef void ARMELChangeHook (ARMCPU *cpu,void *opaque); - +typedef void ARMELChangeHookFn (ARMCPU *cpu,void *opaque); +typedef struct ARMELChangeHook ARMELChangeHook ; +struct ARMELChangeHook { +ARMELChangeHookFn *hook; +void *opaque; +QLIST_ENTRY (ARMELChangeHook) node; +};/* These values map onto the return values for * QEMU_PSCI_0_2_FN_AFFINITY_INFO */ @@ -826,8 +832,7 @@ struct ARMCPU {*/ bool cfgend; -ARMELChangeHook *el_change_hook; -void *el_change_hook_opaque; + QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */ @@ -2895,12 +2900,8 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)* CPU changes exception level or mode. The hook function will be * passed a pointer to the ARMCPU and the opaque data pointer passed * to this function when the hook was registered. -* -* Note that we currently only support registering a single hook function, -* and will assert if this function is called twice. -* This facility is intended for the use of the GICv3 emulation. */ -void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque);/** target/arm/internals.h +4
-3@@ -727,11 +727,12 @@ void arm_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, int mmu_idx, MemTxAttrs attrs, MemTxResult response, uintptr_t retaddr); -/* Call the EL change hook if one has been registered */ +/* Call any registered EL change hooks */ static inline void arm_call_el_change_hook (ARMCPU *cpu) { -if (cpu->el_change_hook) { - cpu->el_change_hook (cpu, cpu->el_change_hook_opaque); +ARMELChangeHook *hook, *next; + QLIST_FOREACH_SAFE(hook, &cpu->el_change_hooks, node, next) { + hook->hook (cpu, hook->opaque); } }
Re: [Qemu-arm] [PATCH v3 08/22] target/arm: Support multiple EL change hooks
Quoted 16 lines · Philippe Mathieu-Daudé
Quoted 15 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 15 ++++++++++----- target/arm/cpu.h | 23 ++++++++++++----------- target/arm/internals.h | 7 ++++--- 3 files changed, 26 insertions(+), 19 deletions(-)target/arm/cpu.c +0
-0@@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); }
Quoted 12 lines
target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 10 lines
target/arm/cpu.c +3
-5-void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) { -/* We currently only support registering a single hook function */ -assert (!cpu->el_change_hook); - cpu->el_change_hook = hook; - cpu->el_change_hook_opaque = opaque; +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));imho
g_malloc()is enough.
It seems like the only difference is between initializing it to zero (g_malloc0) and making it as uninitialized (g_malloc) for coverity. Are there coding standards for when we should choose which?
Quoted 18 lines
Quoted 10 lines
target/arm/cpu.c +5
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->el_change_hooks, entry, node); }static void cp_reg_reset (gpointer key,gpointer value,gpointer opaque)target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 751
Quoted 5 lines
target/arm/cpu.c +2
-0@@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->el_change_hooks); +You missed to fill
arm_cpu_unrealizefn()with:
Quoted 4 lines
QLIST_FOREACH(...) {
QLIST_REMOVE(...);
g_free(...);
}Do you mean arm_cpu_finalizefn()?
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [Qemu-arm] [PATCH v3 08/22] target/arm: Support multiple EL change hooks
Le 20 mars 2018 9:45 PM, "Aaron Lindsay" <[email protected]> a écrit :
Quoted 16 lines · Philippe Mathieu-Daudé
Quoted 15 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 15 ++++++++++----- target/arm/cpu.h | 23 ++++++++++++----------- target/arm/internals.h | 7 ++++--- 3 files changed, 26 insertions(+), 19 deletions(-)target/arm/cpu.c +0
-0@@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); }
Quoted 12 lines
target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 10 lines
target/arm/cpu.c +3
-5-void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) { -/* We currently only support registering a single hook function */ -assert (!cpu->el_change_hook); - cpu->el_change_hook = hook; - cpu->el_change_hook_opaque = opaque; +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));imho
g_malloc()is enough.
It seems like the only difference is between initializing it to zero (g_malloc0) and making it as uninitialized (g_malloc) for coverity. Are there coding standards for when we should choose which?
Since you initialize all members, bzero is not necessary; until someone add another member to the structure. So your way is correct and safer, with a ridiculous performance penalty.
Quoted 10 lines
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev,
Quoted 10 lines
target/arm/cpu.c +5
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->el_change_hooks, entry, node); }static void cp_reg_reset (gpointer key,gpointer value,gpointer opaque)@@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev,
Error **errp)
Quoted 6 lines
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 751
Quoted 5 lines
target/arm/cpu.c +2
-0return ; } +QLIST_INIT (&cpu->el_change_hooks); +
Quoted 6 lines
You missed to fill
arm_cpu_unrealizefn()with:QLIST_FOREACH(...) { QLIST_REMOVE(...); g_free(...); }
Do you mean arm_cpu_finalizefn()?
Yes :)
-Aaron
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [PATCH v3 08/22] target/arm: Support multiple EL change hooks
In reply to Aaron LindsayQuoted 15 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 15 ++++++++++----- target/arm/cpu.h | 23 ++++++++++++----------- target/arm/internals.h | 7 ++++--- 3 files changed, 26 insertions(+), 19 deletions(-)target/arm/cpu.c +0
-0@@ -55,13 +55,16 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); }
target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 10 lines
target/arm/cpu.c +3
-5-void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) { -/* We currently only support registering a single hook function */ -assert (!cpu->el_change_hook); - cpu->el_change_hook = hook; - cpu->el_change_hook_opaque = opaque; +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));
g_new0(ARMELChangeHook, 1) is nicer for initializing a thing of known size.
Quoted 9 lines
target/arm/cpu.c +5
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->el_change_hooks, entry, node); }static void cp_reg_reset (gpointer key,gpointer value,gpointer opaque)
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 751
Quoted 5 lines
target/arm/cpu.c +2
-0@@ -744,6 +747,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->el_change_hooks); +
If you put this in arm_cpu_initfn() you don't have to wonder whether anybody's calling arm_register_el_change_hook() after the CPU object has been created but before it is realized...
Quoted 8 lines
target/arm/cpu.c +0
-0/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 );target/arm/cpu.h +0
-0
target/arm/cpu.h typedef struct CPUARMState { · line 639
Quoted 9 lines
target/arm/cpu.h +3
-2@@ -633,11 +633,17 @@ typedef struct CPUARMState {/** * ARMELChangeHook: -* type of a function which can be registered via arm_register_el_change_hook() -* to get callbacks when the CPU changes its exception level or mode. +* Support registering functions with ARMELChangeHookFn's signature via +* arm_register_el_change_hook() to get callbacks when the CPU changes its +* exception level or mode. */
This is supposed to be the doc comment for the type, which I think was fine as it is, apart from the name change. If you want to also have a doc comment for the struct type that's fine but would be something different (and is less necessary, because the struct type is internal to the CPU whereas the function type is part of its API to the rest of the system).
Quoted 46 lines
target/arm/cpu.h +9
-9-typedef void ARMELChangeHook (ARMCPU *cpu,void *opaque); - +typedef void ARMELChangeHookFn (ARMCPU *cpu,void *opaque); +typedef struct ARMELChangeHook ARMELChangeHook ; +struct ARMELChangeHook { +ARMELChangeHookFn *hook; +void *opaque; +QLIST_ENTRY (ARMELChangeHook) node; +};/* These values map onto the return values for * QEMU_PSCI_0_2_FN_AFFINITY_INFO */ @@ -826,8 +832,7 @@ struct ARMCPU {*/ bool cfgend; -ARMELChangeHook *el_change_hook; -void *el_change_hook_opaque; + QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */ @@ -2895,12 +2900,8 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)* CPU changes exception level or mode. The hook function will be * passed a pointer to the ARMCPU and the opaque data pointer passed * to this function when the hook was registered. -* -* Note that we currently only support registering a single hook function, -* and will assert if this function is called twice. -* This facility is intended for the use of the GICv3 emulation. */ -void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHook *hook, +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque);/** target/arm/internals.h +1
-1@@ -727,11 +727,12 @@ void arm_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, int mmu_idx, MemTxAttrs attrs, MemTxResult response, uintptr_t retaddr); -/* Call the EL change hook if one has been registered */ +/* Call any registered EL change hooks */
target/arm/internals.h void arm_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, · line 738
Quoted 10 lines
target/arm/internals.h +3
-2static inline void arm_call_el_change_hook (ARMCPU *cpu) { -if (cpu->el_change_hook) { - cpu->el_change_hook (cpu, cpu->el_change_hook_opaque); +ARMELChangeHook *hook, *next; + QLIST_FOREACH_SAFE(hook, &cpu->el_change_hooks, node, next) { + hook->hook (cpu, hook->opaque); } }
thanks
-- PMM
PATCH v3 9/22 target/arm: Add pre-EL change hooks
In reply to Aaron LindsayBecause the design of the PMU requires that the counter values be converted between their delta and guest-visible forms for mode filtering, an additional hook which occurs before the EL is changed is necessary.
--- target/arm/cpu.c | 13 +++++++++++++ target/arm/cpu.h | 12 ++++++++---- target/arm/helper.c | 14 ++++++++------ target/arm/internals.h | 7 +++++++ target/arm/op_helper.c | 8 ++++++++ 5 files changed, 44 insertions(+), 10 deletions(-)
target/arm/cpu.c +13 -0
@@ -55,6 +55,18 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); } +void arm_register_pre_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook, +void *opaque) +{ +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry)); + + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->pre_el_change_hooks, entry, node); +} +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) {
@@ -747,6 +759,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->pre_el_change_hooks);QLIST_INIT (&cpu->el_change_hooks);/* Some features automatically imply others: */
target/arm/cpu.h +8 -4
@@ -832,6 +832,7 @@ struct ARMCPU {*/ bool cfgend; + QLIST_HEAD(, ARMELChangeHook) pre_el_change_hooks; QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */
@@ -2895,12 +2896,15 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)#endif /** +* arm_register_pre_el_change_hook: * arm_register_el_change_hook: -* Register a hook function which will be called back whenever this -* CPU changes exception level or mode. The hook function will be -* passed a pointer to the ARMCPU and the opaque data pointer passed -* to this function when the hook was registered. +* Register a hook function which will be called back before or after this CPU +* changes exception level or mode. The hook function will be passed a pointer +* to the ARMCPU and the opaque data pointer passed to this function when the +* hook was registered. */ +void arm_register_pre_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook, +void *opaque);void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque);
target/arm/helper.c +8 -6
@@ -8253,6 +8253,14 @@ void arm_cpu_do_interrupt(CPUState *cs)return ; } +/* Hooks may change global state so BQL should be held, also the +* BQL needs to be held for any modification of +* cs->interrupt_request. +*/ +g_assert (qemu_mutex_iothread_locked ()); + +arm_call_pre_el_change_hook (cpu); +assert (!excp_is_internal (cs->exception_index));if (arm_el_is_aa64 (env, new_el)) {arm_cpu_do_interrupt_aarch64 (cs);
@@ -8260,12 +8268,6 @@ void arm_cpu_do_interrupt(CPUState *cs)arm_cpu_do_interrupt_aarch32 (cs); } -/* Hooks may change global state so BQL should be held, also the -* BQL needs to be held for any modification of -* cs->interrupt_request. -*/ -g_assert (qemu_mutex_iothread_locked ()); -arm_call_el_change_hook (cpu);if (!kvm_enabled ()) {
target/arm/internals.h +7 -0
@@ -728,6 +728,13 @@ void arm_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, MemTxResult response, uintptr_t retaddr);/* Call any registered EL change hooks */ +static inline void arm_call_pre_el_change_hook (ARMCPU *cpu) +{ +ARMELChangeHook *hook, *next; + QLIST_FOREACH_SAFE(hook, &cpu->pre_el_change_hooks, node, next) { + hook->hook (cpu, hook->opaque); + } +}static inline void arm_call_el_change_hook (ARMCPU *cpu) {ARMELChangeHook *hook, *next;
target/arm/op_helper.c +8 -0
@@ -496,6 +496,10 @@ void HELPER(cpsr_write)(CPUARMState *env, uint32_t val, uint32_t mask)/* Write the CPSR for a 32-bit exception return */ void HELPER (cpsr_write_eret )(CPUARMState *env,uint32_t val) { +qemu_mutex_lock_iothread (); +arm_call_pre_el_change_hook (arm_env_get_cpu (env)); +qemu_mutex_unlock_iothread (); +cpsr_write (env, val,CPSR_ERET_MASK , CPSRWriteExceptionReturn);/* Generated code has already stored the new PC value, but
@@ -1013,6 +1017,10 @@ void HELPER(exception_return)(CPUARMState *env) goto illegal_return; } +qemu_mutex_lock_iothread (); +arm_call_pre_el_change_hook (arm_env_get_cpu (env)); +qemu_mutex_unlock_iothread (); +if (!return_to_aa64) { env->aarch64 =0 ;/* We do a raw CPSR write because aarch64_sync_64_to_32()
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 09/22] target/arm: Add pre-EL change hooks
Quoted 19 lines · Aaron Lindsay
Because the design of the PMU requires that the counter values be converted between their delta and guest-visible forms for mode filtering, an additional hook which occurs before the EL is changed is necessary.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 13 +++++++++++++ target/arm/cpu.h | 12 ++++++++---- target/arm/helper.c | 14 ++++++++------ target/arm/internals.h | 7 +++++++ target/arm/op_helper.c | 8 ++++++++ 5 files changed, 44 insertions(+), 10 deletions(-)target/arm/cpu.c +0
-0
target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 8 lines
target/arm/cpu.c +5
-0@@ -55,6 +55,18 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); } +void arm_register_pre_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook, +void *opaque) +{ +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));
g_new0().
Quoted 35 lines
target/arm/cpu.c +8
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->pre_el_change_hooks, entry, node); +} +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) {@@ -747,6 +759,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->pre_el_change_hooks);QLIST_INIT (&cpu->el_change_hooks);/* Some features automatically imply others: */ target/arm/cpu.h +2
-0@@ -832,6 +832,7 @@ struct ARMCPU {*/ bool cfgend; + QLIST_HEAD(, ARMELChangeHook) pre_el_change_hooks; QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */ @@ -2895,12 +2896,15 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)#endif /** +* arm_register_pre_el_change_hook:
target/arm/cpu.h static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs) · line 2905
Quoted 10 lines
target/arm/cpu.h +4
-4* arm_register_el_change_hook: -* Register a hook function which will be called back whenever this -* CPU changes exception level or mode. The hook function will be -* passed a pointer to the ARMCPU and the opaque data pointer passed -* to this function when the hook was registered. +* Register a hook function which will be called back before or after this CPU +* changes exception level or mode. The hook function will be passed a pointer +* to the ARMCPU and the opaque data pointer passed to this function when the +* hook was registered. */
I would just have one doc comment for each function, rather than trying to share. (Some day we may actually autogenerate HTML docs from these comments...)
Do we make the guarantee that if we call the pre-change hook then we will definitely subsequently call the post-change hook? (ie does the PMU hook rely on that?)
Otherwise looks OK.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 09/22] target/arm: Add pre-EL change hooks
Quoted 81 lines · Peter Maydell
Quoted 19 lines · Aaron Lindsay
Because the design of the PMU requires that the counter values be converted between their delta and guest-visible forms for mode filtering, an additional hook which occurs before the EL is changed is necessary.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 13 +++++++++++++ target/arm/cpu.h | 12 ++++++++---- target/arm/helper.c | 14 ++++++++------ target/arm/internals.h | 7 +++++++ target/arm/op_helper.c | 8 ++++++++ 5 files changed, 44 insertions(+), 10 deletions(-)target/arm/cpu.c +0
-0target/arm/cpu.c static bool arm_cpu_has_work(CPUState *cs) · line 62
Quoted 8 lines
target/arm/cpu.c +5
-0@@ -55,6 +55,18 @@ static bool arm_cpu_has_work(CPUState *cs) | CPU_INTERRUPT_EXITTB); } +void arm_register_pre_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook, +void *opaque) +{ +ARMELChangeHook *entry; + entry =g_malloc0 (sizeof (*entry));
g_new0().Quoted 35 lines
target/arm/cpu.c +8
-0+ + entry->hook = hook; + entry->opaque = opaque; + +QLIST_INSERT_HEAD (&cpu->pre_el_change_hooks, entry, node); +} +void arm_register_el_change_hook (ARMCPU *cpu,ARMELChangeHookFn *hook,void *opaque) {@@ -747,6 +759,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)return ; } +QLIST_INIT (&cpu->pre_el_change_hooks);QLIST_INIT (&cpu->el_change_hooks);/* Some features automatically imply others: */ target/arm/cpu.h +2
-0@@ -832,6 +832,7 @@ struct ARMCPU {*/ bool cfgend; + QLIST_HEAD(, ARMELChangeHook) pre_el_change_hooks; QLIST_HEAD(, ARMELChangeHook) el_change_hooks;int32_t node_id;/* NUMA node this CPU belongs to */ @@ -2895,12 +2896,15 @@ static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs)#endif /** +* arm_register_pre_el_change_hook: target/arm/cpu.h static inline AddressSpace *arm_addressspace(CPUState *cs, MemTxAttrs attrs) · line 2905
Quoted 10 lines
target/arm/cpu.h +4
-4* arm_register_el_change_hook: -* Register a hook function which will be called back whenever this -* CPU changes exception level or mode. The hook function will be -* passed a pointer to the ARMCPU and the opaque data pointer passed -* to this function when the hook was registered. +* Register a hook function which will be called back before or after this CPU +* changes exception level or mode. The hook function will be passed a pointer +* to the ARMCPU and the opaque data pointer passed to this function when the +* hook was registered. */ I would just have one doc comment for each function, rather than trying to share. (Some day we may actually autogenerate HTML docs from these comments...)
Quoted 3 lines
Do we make the guarantee that if we call the pre-change hook then we will definitely subsequently call the post-change hook? (ie does the PMU hook rely on that?)
Yes, the PMU relies on the pre- and post- hooks being called in pairs since they drive the state machine of sorts that exists in the variables holding the counter values/deltas. And unless I've really screwed up the implementation, I believe the change hooks in my patchset make that guarantee.
-Aaron
Quoted 5 lines
Otherwise looks OK.
thanks
-- PMM
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 09/22] target/arm: Add pre-EL change hooks
Quoted 10 lines · Aaron Lindsay
Quoted 3 lines · Peter Maydell
Do we make the guarantee that if we call the pre-change hook then we will definitely subsequently call the post-change hook? (ie does the PMU hook rely on that?)
Yes, the PMU relies on the pre- and post- hooks being called in pairs since they drive the state machine of sorts that exists in the variables holding the counter values/deltas. And unless I've really screwed up the implementation, I believe the change hooks in my patchset make that guarantee.
Yes, I think I agree. We should document in the comment that this is a guarantee that we make.
thanks
-- PMM
PATCH v3 10/22 target/arm: Allow EL change hooks to do IO
In reply to Aaron LindsayDuring code generation, surround CPSR writes and exception returns which call the EL change hooks with gen_io_start/end. The immediate need is for the PMU to access the clock and icount during EL change to support mode filtering.
--- target/arm/translate-a64.c | 2 ++ target/arm/translate.c | 4 ++++ 2 files changed, 6 insertions(+)
target/arm/translate-a64.c +2 -0
@@ -1919,7 +1919,9 @@ static void disas_uncond_b_reg(DisasContext *s, uint32_t insn)unallocated_encoding (s);return ; } +gen_io_start ();gen_helper_exception_return (cpu_env); +gen_io_end ();/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;return ;
target/arm/translate.c +4 -0
@@ -4536,7 +4536,9 @@ static void gen_rfe(DisasContext *s, TCGv_i32 pc, TCGv_i32 cpsr)* appropriately depending on the new Thumb bit, so it must * be called after storing the new PC. */ +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, cpsr); +gen_io_end ();tcg_temp_free_i32 (cpsr);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;
@@ -9828,7 +9830,9 @@ static void disas_arm_insn(DisasContext *s, unsigned int insn)if (exc_return) {/* Restore CPSR from SPSR. */ tmp =load_cpu_field (spsr); +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, tmp); +gen_io_end ();tcg_temp_free_i32 (tmp);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 10/22] target/arm: Allow EL change hooks to do IO
Quoted 16 lines · Aaron Lindsay
During code generation, surround CPSR writes and exception returns which call the EL change hooks with gen_io_start/end. The immediate need is for the PMU to access the clock and icount during EL change to support mode filtering.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/translate-a64.c | 2 ++ target/arm/translate.c | 4 ++++ 2 files changed, 6 insertions(+)target/arm/translate-a64.c +0
-0
target/arm/translate-a64.c static void disas_uncond_b_reg(DisasContext *s, uint32_t insn) · line 1924
Quoted 6 lines
target/arm/translate-a64.c +2
-0@@ -1919,7 +1919,9 @@ static void disas_uncond_b_reg(DisasContext *s, uint32_t insn)unallocated_encoding (s);return ; } +gen_io_start ();gen_helper_exception_return (cpu_env); +gen_io_end ();
You don't want to call gen_io_start() or gen_io_end() unless tb_cflags(s->base.tb) & CF_USE_ICOUNT) is true.
(Ditto in the other cases below.)
Quoted 28 lines
target/arm/translate-a64.c +0
-0/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;return ;target/arm/translate.c +4
-1@@ -4536,7 +4536,9 @@ static void gen_rfe(DisasContext *s, TCGv_i32 pc, TCGv_i32 cpsr)* appropriately depending on the new Thumb bit, so it must * be called after storing the new PC. */ +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, cpsr); +gen_io_end ();tcg_temp_free_i32 (cpsr);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;@@ -9828,7 +9830,9 @@ static void disas_arm_insn(DisasContext *s, unsigned int insn)if (exc_return) {/* Restore CPSR from SPSR. */ tmp =load_cpu_field (spsr); +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, tmp); +gen_io_end ();tcg_temp_free_i32 (tmp);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ; --
Quoted 4 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 10/22] target/arm: Allow EL change hooks to do IO
Quoted 27 lines · Peter Maydell
Quoted 16 lines · Aaron Lindsay
During code generation, surround CPSR writes and exception returns which call the EL change hooks with gen_io_start/end. The immediate need is for the PMU to access the clock and icount during EL change to support mode filtering.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/translate-a64.c | 2 ++ target/arm/translate.c | 4 ++++ 2 files changed, 6 insertions(+)target/arm/translate-a64.c +0
-0target/arm/translate-a64.c static void disas_uncond_b_reg(DisasContext *s, uint32_t insn) · line 1924
Quoted 6 lines
target/arm/translate-a64.c +2
-0@@ -1919,7 +1919,9 @@ static void disas_uncond_b_reg(DisasContext *s, uint32_t insn)unallocated_encoding (s);return ; } +gen_io_start ();gen_helper_exception_return (cpu_env); +gen_io_end ();You don't want to call
gen_io_start()orgen_io_end()unlesstb_cflags(s->base.tb)&CF_USE_ICOUNT) is true.
Quoted 1 line
(Ditto in the other cases below.)
I assume there's nothing tricky about this and updating this as follows is sufficient?
Quoted 7 lines
target/arm/translate-a64.c static void disas_uncond_b_reg(DisasContext *s, uint32_t insn)
Quoted 7 lines
target/arm/translate-a64.c +6
-0+if (tb_cflags (s->base.tb) &CF_USE_ICOUNT ) { +gen_io_start (); + }gen_helper_exception_return (cpu_env); +if (tb_cflags (s->base.tb) &CF_USE_ICOUNT ) { +gen_io_end (); + }
-Aaron
Quoted 36 lines
Quoted 29 lines
/* Must exit loop to check un-masked IRQs */ s->base.is_jmp = DISAS_EXIT; return;target/arm/translate.c +4
-1@@ -4536,7 +4536,9 @@ static void gen_rfe(DisasContext *s, TCGv_i32 pc, TCGv_i32 cpsr)* appropriately depending on the new Thumb bit, so it must * be called after storing the new PC. */ +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, cpsr); +gen_io_end ();tcg_temp_free_i32 (cpsr);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ;@@ -9828,7 +9830,9 @@ static void disas_arm_insn(DisasContext *s, unsigned int insn)if (exc_return) {/* Restore CPSR from SPSR. */ tmp =load_cpu_field (spsr); +gen_io_start ();gen_helper_cpsr_write_eret (cpu_env, tmp); +gen_io_end ();tcg_temp_free_i32 (tmp);/* Must exit loop to check un-masked IRQs */ s->base.is_jmp =DISAS_EXIT ; --Quoted 4 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.thanks
-- PMM
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 10/22] target/arm: Allow EL change hooks to do IO
Quoted 28 lines · Aaron Lindsay
Quoted 27 lines · Peter Maydell
Quoted 16 lines · Aaron Lindsay
During code generation, surround CPSR writes and exception returns which call the EL change hooks with gen_io_start/end. The immediate need is for the PMU to access the clock and icount during EL change to support mode filtering.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/translate-a64.c | 2 ++ target/arm/translate.c | 4 ++++ 2 files changed, 6 insertions(+)target/arm/translate-a64.c +0
-0target/arm/translate-a64.c static void disas_uncond_b_reg(DisasContext *s, uint32_t insn) · line 1924
Quoted 6 lines
target/arm/translate-a64.c +2
-0@@ -1919,7 +1919,9 @@ static void disas_uncond_b_reg(DisasContext *s, uint32_t insn)unallocated_encoding (s);return ; } +gen_io_start ();gen_helper_exception_return (cpu_env); +gen_io_end ();You don't want to call
gen_io_start()orgen_io_end()unlesstb_cflags(s->base.tb)&CF_USE_ICOUNT) is true.
Quoted 4 lines
Quoted 1 line
(Ditto in the other cases below.)
I assume there's nothing tricky about this and updating this as follows is sufficient?
Yes, that's sufficient. (The other thing that needs to happen for a gen_io_start/end is that the insn has to end the TB -- but in all these cases that's already true as they set s->base.is_jmp = DISAS_EXIT.)
thanks
-- PMM
PATCH v3 11/22 target/arm: Fix bitmask for PMCCFILTR writes
In reply to Aaron LindsayIt was shifted to the left one bit too few.
--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
target/arm/helper.c +1 -1
@@ -1123,7 +1123,7 @@ static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) {uint64_t saved_cycles =pmccntr_op_start (env); - env->cp15.pmccfiltr_el0 = value &0x7E000000 ; + env->cp15.pmccfiltr_el0 = value &0xfc000000 ;pmccntr_op_finish (env, saved_cycles); }
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [PATCH v3 11/22] target/arm: Fix bitmask for PMCCFILTR writes
Quoted 12 lines · Aaron Lindsay
It was shifted to the left one bit too few.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/helper.c +0
-0
target/arm/helper.c static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, · line 1129
Quoted 8 lines
target/arm/helper.c +1
-1@@ -1123,7 +1123,7 @@ static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) {uint64_t saved_cycles =pmccntr_op_start (env); - env->cp15.pmccfiltr_el0 = value &0x7E000000 ; + env->cp15.pmccfiltr_el0 = value &0xfc000000 ;pmccntr_op_finish (env, saved_cycles); }
I wonder why we got that one wrong.
Strictly speaking, bit 26 (M) should be visible only in the AArch64 view of the register, not the AArch32 one, but that's a separate issue.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 11/22] target/arm: Fix bitmask for PMCCFILTR writes
Quoted 24 lines · Peter Maydell
Quoted 12 lines · Aaron Lindsay
It was shifted to the left one bit too few.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/helper.c +0
-0target/arm/helper.c static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, · line 1129
Quoted 8 lines
target/arm/helper.c +1
-1@@ -1123,7 +1123,7 @@ static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) {uint64_t saved_cycles =pmccntr_op_start (env); - env->cp15.pmccfiltr_el0 = value &0x7E000000 ; + env->cp15.pmccfiltr_el0 = value &0xfc000000 ;pmccntr_op_finish (env, saved_cycles); }I wonder why we got that one wrong.
Quoted 5 lines
Reviewed-by Peter Maydell <[email protected]>Strictly speaking, bit 26 (M) should be visible only in the AArch64 view of the register, not the AArch32 one, but that's a separate issue.
Right. I addressed this when I added AArch32 access for PMCCFILTR:
[PATCH v3 13/22] target/arm: Allow AArch32 access for PMCCFILTR https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04910.html
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 12/22 target/arm: Filter cycle counter based on PMCCFILTR_EL0
In reply to Aaron LindsayThe pmu_counter_filtered and pmu_op_start/finish functions are generic (as opposed to PMCCNTR-specific) to allow for the implementation of other events.
--- target/arm/cpu.c | 3 ++ target/arm/cpu.h | 37 +++++++++++++++++++---- target/arm/helper.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 11 deletions(-)
target/arm/cpu.c +3 -0
@@ -887,6 +887,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)if (!cpu->has_pmu) {unset_feature (env,ARM_FEATURE_PMU ); cpu->id_aa64dfr0 &= ~0xf00 ; + }else { +arm_register_pre_el_change_hook (cpu, &pmu_pre_el_change,0 ); +arm_register_el_change_hook (cpu, &pmu_post_el_change,0 ); }if (!arm_feature (env,ARM_FEATURE_EL2 )) {
target/arm/cpu.h +31 -6
@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt; +/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;uint64_t pmccfiltr_el0;/* Performance Monitor Filter Register */ uint64_t vpidr_el2;/* Virtualization Processor ID Register */ uint64_t vmpidr_el2;/* Virtualization Multiprocessor ID Register */
@@ -896,15 +901,35 @@ int cpu_arm_signal_handler(int host_signum, void *pinfo, void *puc);/** -* pmccntr_sync +* pmccntr_op_start/finish * @env: CPUARMState * -* Synchronises the counter in the PMCCNTR. This must always be called twice, -* once before any action that might affect the timer and again afterwards. -* The function is used to swap the state of the register if required. -* This only happens when not in user mode (!CONFIG_USER_ONLY) +* Convert the counter in the PMCCNTR between its delta form (the typical mode +* when it's enabled) and the guest-visible value. These two calls must always +* surround any action which might affect the counter, and the return value +* from pmccntr_op_start must be supplied as the second argument to +* pmccntr_op_finish. +*/ +uint64_t pmccntr_op_start (CPUARMState *env); +void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* pmu_op_start/finish +* @env: CPUARMState +* +* Convert all PMU counters between their delta form (the typical mode when +* they are enabled) and the guest-visible values. These two calls must +* surround any action which might affect the counters, and the return value +* from pmu_op_start must be supplied as the second argument to pmu_op_finish. +*/ +uint64_t pmu_op_start (CPUARMState *env); +void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* Functions to register as EL change hooks for PMU mode filtering */ -void pmccntr_sync (CPUARMState *env); +void pmu_pre_el_change (ARMCPU *cpu,void *ignored); +void pmu_post_el_change (ARMCPU *cpu,void *ignored);/* SCTLR bit meanings. Several bits have been reused in newer * versions of the architecture; in that case we define constants
target/arm/helper.c +82 -5
138 lines not on this page · raw message
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 12/22] target/arm: Filter cycle counter based on PMCCFILTR_EL0
Quoted 16 lines · Aaron Lindsay
The
pmu_counter_filteredand pmu_op_start/finish functions are generic (as opposed to PMCCNTR-specific) to allow for the implementation of other events.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 3 ++ target/arm/cpu.h | 37 +++++++++++++++++++---- target/arm/helper.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 11 deletions(-)target/arm/cpu.c +0
-0
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 892
Quoted 6 lines
target/arm/cpu.c +3
-0@@ -887,6 +887,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)if (!cpu->has_pmu) {unset_feature (env,ARM_FEATURE_PMU ); cpu->id_aa64dfr0 &= ~0xf00 ; + }else { +arm_register_pre_el_change_hook (cpu, &pmu_pre_el_change,0 ); +arm_register_el_change_hook (cpu, &pmu_post_el_change,0 );
You probably don't want to do this if we're using KVM, as there are some code paths where we call do_interrupt() when using KVM which will trigger the hooks and likely do unexpected things. (For instance kvm_arm_handle_debug() does this to set the guest up to take debug exceptions.)
Quoted 8 lines
target/arm/cpu.c +0
-0}if (!arm_feature (env,ARM_FEATURE_EL2 )) {target/arm/cpu.h +0
-0
target/arm/cpu.h typedef struct CPUARMState { · line 465
Quoted 8 lines
target/arm/cpu.h +5
-0@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt; +/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;
Can this ever hold valid state at a point when we need to do VM migration, or is it purely temporary ?
target/arm/cpu.h int cpu_arm_signal_handler(int host_signum, void *pinfo, · line 904
Quoted 9 lines
target/arm/cpu.h +1
-1uint64_t pmccfiltr_el0;/* Performance Monitor Filter Register */ uint64_t vpidr_el2;/* Virtualization Processor ID Register */ uint64_t vmpidr_el2;/* Virtualization Multiprocessor ID Register */ @@ -896,15 +901,35 @@ int cpu_arm_signal_handler(int host_signum, void *pinfo, void *puc);/** -* pmccntr_sync +* pmccntr_op_start/finish
Shouldn't this doc change and prototype change have gone with the earlier patch that changed the implementation?
Quoted 66 lines
target/arm/cpu.h +25
-5* @env: CPUARMState * -* Synchronises the counter in the PMCCNTR. This must always be called twice, -* once before any action that might affect the timer and again afterwards. -* The function is used to swap the state of the register if required. -* This only happens when not in user mode (!CONFIG_USER_ONLY) +* Convert the counter in the PMCCNTR between its delta form (the typical mode +* when it's enabled) and the guest-visible value. These two calls must always +* surround any action which might affect the counter, and the return value +* from pmccntr_op_start must be supplied as the second argument to +* pmccntr_op_finish. +*/ +uint64_t pmccntr_op_start (CPUARMState *env); +void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* pmu_op_start/finish +* @env: CPUARMState +* +* Convert all PMU counters between their delta form (the typical mode when +* they are enabled) and the guest-visible values. These two calls must +* surround any action which might affect the counters, and the return value +* from pmu_op_start must be supplied as the second argument to pmu_op_finish. +*/ +uint64_t pmu_op_start (CPUARMState *env); +void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* Functions to register as EL change hooks for PMU mode filtering */ -void pmccntr_sync (CPUARMState *env); +void pmu_pre_el_change (ARMCPU *cpu,void *ignored); +void pmu_post_el_change (ARMCPU *cpu,void *ignored);/* SCTLR bit meanings. Several bits have been reused in newer * versions of the architecture; in that case we define constants target/arm/helper.c +10
-1@@ -908,6 +908,15 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {#define PMCRC 0x4#define PMCRE 0x1 +#define PMXEVTYPER_P 0x80000000 +#define PMXEVTYPER_U 0x40000000 +#define PMXEVTYPER_NSK 0x20000000 +#define PMXEVTYPER_NSU 0x10000000 +#define PMXEVTYPER_NSH 0x08000000 +#define PMXEVTYPER_M 0x04000000 +#define PMXEVTYPER_MT 0x02000000 +#define PMXEVTYPER_EVTCOUNT 0x000003ff +#define PMU_NUM_COUNTERS (env) ((env->cp15.c9_pmcr & PMCRN_MASK) >> PMCRN_SHIFT)/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ #define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1))@@ -998,7 +1007,7 @@ static CPAccessResult pmreg_access_ccntr(CPUARMState *env,static inline bool arm_ccnt_enabled (CPUARMState *env) { -/* This does not support checking PMCCFILTR_EL0 register */ +/* Does not check PMCCFILTR_EL0, which is handled by pmu_counter_filtered */ if (!(env->cp15.c9_pmcr &PMCRE ) || !(env->cp15.c9_pmcnten & (1 <<31 ))) {return false;
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1020
Quoted 6 lines
target/arm/helper.c +3
-0@@ -1006,6 +1015,44 @@ static inline bool arm_ccnt_enabled(CPUARMState *env)return true; } + +/* Returns true if the counter corresponding to the passed-in pmevtyper or +* pmccfiltr value is filtered using the current state */
"is filtered (ie does not count events)" would make it clearer.
Nit: */ should be on a line of its own.
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1031
Quoted 11 lines
target/arm/helper.c +11
-0+static inline bool pmu_counter_filtered (CPUARMState *env,uint64_t pmxevtyper) +{ +bool secure =arm_is_secure (env); +int el =arm_current_el (env); + +bool P = pmxevtyper &PMXEVTYPER_P ; +bool U = pmxevtyper &PMXEVTYPER_U ; +bool NSK = pmxevtyper &PMXEVTYPER_NSK ; +bool NSU = pmxevtyper &PMXEVTYPER_NSU ; +bool NSH = pmxevtyper &PMXEVTYPER_NSH ; +bool M = pmxevtyper &PMXEVTYPER_M ;
Lowercase for variable names, please.
Quoted 10 lines
target/arm/helper.c +10
-0+ +if (el ==1 &&P ) { +return true; + }else if (el ==0 &&U ) { +return true; + } + +if (arm_feature (env,ARM_FEATURE_EL3 )) { +if (el ==1 && !secure &&NSK !=P ) { +return true;
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1051
Quoted 10 lines
target/arm/helper.c +10
-0+ }else if (el ==0 && !secure &&NSU !=U ) { +return true; + }else if (el ==3 && secure &&M !=P ) { +return true; + } + } + +if (arm_feature (env,ARM_FEATURE_EL2 ) && el ==2 && !secure && !NSH ) { +return true; + }
This doesn't follow the structure that the Arm ARM pseudocode uses, which makes it a bit tricky to review. (see AArch64.CountEvents()). It also doesn't implement the same logic -- for instance this code will return true if we're in NS EL1 and the U bit is set, whereas the pseudocode returns true for NS EL1 only if U != NSU.
Quoted 26 lines
target/arm/helper.c +7
-2+return false; +} +/* * Ensure c15_ccnt is the guest-visible count so that operations such as * enabling/disabling the counter or filtering, modifying the count itself, @@ -1023,7 +1070,8 @@ uint64_t pmccntr_op_start(CPUARMState *env) ARM_CPU_FREQ, NANOSECONDS_PER_SECOND);#endif -if (arm_ccnt_enabled (env)) { +if (arm_ccnt_enabled (env) && + !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {uint64_t eff_cycles = cycles;if (env->cp15.c9_pmcr &PMCRD ) {@@ -1043,7 +1091,8 @@ uint64_t pmccntr_op_start(CPUARMState *env)*/ void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) { -if (arm_ccnt_enabled (env)) { +if (arm_ccnt_enabled (env) && + !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {if (env->cp15.c9_pmcr &PMCRD ) {/* Increment once every 64 processor clock cycles */
target/arm/helper.c void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles) · line 1109
Quoted 7 lines
target/arm/helper.c +4
-0@@ -1054,10 +1103,30 @@ void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles) } } +uint64_t pmu_op_start (CPUARMState *env) +{ +return pmccntr_op_start (env); +}
Do these two functions end up being different at the end of the patchset?
Quoted 39 lines
target/arm/helper.c +20
-2+ +void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles) +{ +pmccntr_op_finish (env, prev_cycles); +} + +void pmu_pre_el_change (ARMCPU *cpu,void *ignored) +{ + cpu->env.cp15.ccnt_cached_cycles =pmu_op_start (&cpu->env); +} + +void pmu_post_el_change (ARMCPU *cpu,void *ignored) +{ +pmu_op_finish (&cpu->env, cpu->env.cp15.ccnt_cached_cycles); +} +static void pmcr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { -uint64_t saved_cycles =pmccntr_op_start (env); +uint64_t saved_cycles =pmu_op_start (env);if (value &PMCRC ) {/* The counter has been reset */ @@ -1068,7 +1137,7 @@ static void pmcr_write(CPUARMState *env, const ARMCPRegInfo *ri, env->cp15.c9_pmcr &= ~0x39 ; env->cp15.c9_pmcr |= (value &0x39 ); -pmccntr_op_finish (env, saved_cycles); +pmu_op_finish (env, saved_cycles); }static uint64_t pmccntr_read (CPUARMState *env,const ARMCPRegInfo *ri)@@ -1117,6 +1186,14 @@ void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles) { } +uint64_t pmu_op_start (CPUARMState *env) +{
target/arm/helper.c void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles)
Quoted 10 lines
target/arm/helper.c +6
-1+} + +void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles) +{ +} +#endif static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, --
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 12/22] target/arm: Filter cycle counter based on PMCCFILTR_EL0
Quoted 21 lines · Peter Maydell
Quoted 20 lines · Aaron Lindsay
The
pmu_counter_filteredand pmu_op_start/finish functions are generic (as opposed to PMCCNTR-specific) to allow for the implementation of other events.Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 3 ++ target/arm/cpu.h | 37 +++++++++++++++++++---- target/arm/helper.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 11 deletions(-)target/arm/cpu.c +1
-0@@ -887,6 +887,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)if (!cpu->has_pmu) {unset_feature (env,ARM_FEATURE_PMU ); cpu->id_aa64dfr0 &= ~0xf00 ; + }else {
Quoted 8 lines
target/arm/cpu.c static void arm_cpu_realizefn(DeviceState *dev, Error **errp) · line 892
Quoted 2 lines
target/arm/cpu.c +2
-0+arm_register_pre_el_change_hook (cpu, &pmu_pre_el_change,0 ); +arm_register_el_change_hook (cpu, &pmu_post_el_change,0 );You probably don't want to do this if we're using KVM, as there are some code paths where we call
do_interrupt()when using KVM which will trigger the hooks and likely do unexpected things. (For instancekvm_arm_handle_debug()does this to set the guest up to take debug exceptions.)
Okay, I'll surround this with if (!kvm_enabled()) for the next pass.
Quoted 12 lines
Quoted 12 lines
target/arm/cpu.c +0
-0}if (!arm_feature (env,ARM_FEATURE_EL2 )) {target/arm/cpu.h +0
-0@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt;
Quoted 8 lines
target/arm/cpu.h typedef struct CPUARMState { · line 465
Quoted 5 lines
target/arm/cpu.h +5
-0+/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;Can this ever hold valid state at a point when we need to do VM migration, or is it purely temporary ?
I believe that as of this version of the patch it is temporary and will not need to be migrated. However, I believe it's going to be necessary to have two variables to represent the state of each counter in order to implement interrupt on overflow.
Quoted 7 lines
Quoted 7 lines
target/arm/cpu.h +0
-0uint64_t pmccfiltr_el0;/* Performance Monitor Filter Register */ uint64_t vpidr_el2;/* Virtualization Processor ID Register */ uint64_t vmpidr_el2;/* Virtualization Multiprocessor ID Register */ @@ -896,15 +901,35 @@ int cpu_arm_signal_handler(int host_signum, void *pinfo, void *puc);
Quoted 6 lines
target/arm/cpu.h int cpu_arm_signal_handler(int host_signum, void *pinfo, · line 904
Quoted 3 lines
target/arm/cpu.h +1
-1/** -* pmccntr_sync +* pmccntr_op_start/finish Shouldn't this doc change and prototype change have gone with the earlier patch that changed the implementation?
Hmmm, yes. Seems like I got pmccntr_op_start and pmu_op_start confused when staging this.
Quoted 75 lines
Quoted 66 lines
target/arm/cpu.h +25
-5* @env: CPUARMState * -* Synchronises the counter in the PMCCNTR. This must always be called twice, -* once before any action that might affect the timer and again afterwards. -* The function is used to swap the state of the register if required. -* This only happens when not in user mode (!CONFIG_USER_ONLY) +* Convert the counter in the PMCCNTR between its delta form (the typical mode +* when it's enabled) and the guest-visible value. These two calls must always +* surround any action which might affect the counter, and the return value +* from pmccntr_op_start must be supplied as the second argument to +* pmccntr_op_finish. +*/ +uint64_t pmccntr_op_start (CPUARMState *env); +void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* pmu_op_start/finish +* @env: CPUARMState +* +* Convert all PMU counters between their delta form (the typical mode when +* they are enabled) and the guest-visible values. These two calls must +* surround any action which might affect the counters, and the return value +* from pmu_op_start must be supplied as the second argument to pmu_op_finish. +*/ +uint64_t pmu_op_start (CPUARMState *env); +void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles); + +/** +* Functions to register as EL change hooks for PMU mode filtering */ -void pmccntr_sync (CPUARMState *env); +void pmu_pre_el_change (ARMCPU *cpu,void *ignored); +void pmu_post_el_change (ARMCPU *cpu,void *ignored);/* SCTLR bit meanings. Several bits have been reused in newer * versions of the architecture; in that case we define constants target/arm/helper.c +10
-1@@ -908,6 +908,15 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {#define PMCRC 0x4#define PMCRE 0x1 +#define PMXEVTYPER_P 0x80000000 +#define PMXEVTYPER_U 0x40000000 +#define PMXEVTYPER_NSK 0x20000000 +#define PMXEVTYPER_NSU 0x10000000 +#define PMXEVTYPER_NSH 0x08000000 +#define PMXEVTYPER_M 0x04000000 +#define PMXEVTYPER_MT 0x02000000 +#define PMXEVTYPER_EVTCOUNT 0x000003ff +#define PMU_NUM_COUNTERS (env) ((env->cp15.c9_pmcr & PMCRN_MASK) >> PMCRN_SHIFT)/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ #define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1))@@ -998,7 +1007,7 @@ static CPAccessResult pmreg_access_ccntr(CPUARMState *env,static inline bool arm_ccnt_enabled (CPUARMState *env) { -/* This does not support checking PMCCFILTR_EL0 register */ +/* Does not check PMCCFILTR_EL0, which is handled by pmu_counter_filtered */ if (!(env->cp15.c9_pmcr &PMCRE ) || !(env->cp15.c9_pmcnten & (1 <<31 ))) {return false;target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1020
Quoted 6 lines
target/arm/helper.c +3
-0@@ -1006,6 +1015,44 @@ static inline bool arm_ccnt_enabled(CPUARMState *env)return true; } + +/* Returns true if the counter corresponding to the passed-in pmevtyper or +* pmccfiltr value is filtered using the current state */ "is filtered (ie does not count events)" would make it clearer.
Quoted 1 line
Nit: */ should be on a line of its own.
Will do.
Quoted 14 lines
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1031
Quoted 12 lines
target/arm/helper.c +11
-0+static inline bool pmu_counter_filtered (CPUARMState *env,uint64_t pmxevtyper) +{ +bool secure =arm_is_secure (env); +int el =arm_current_el (env); + +bool P = pmxevtyper &PMXEVTYPER_P ; +bool U = pmxevtyper &PMXEVTYPER_U ; +bool NSK = pmxevtyper &PMXEVTYPER_NSK ; +bool NSU = pmxevtyper &PMXEVTYPER_NSU ; +bool NSH = pmxevtyper &PMXEVTYPER_NSH ; +bool M = pmxevtyper &PMXEVTYPER_M ;Lowercase for variable names, please.
Will do.
Quoted 18 lines
Quoted 18 lines
target/arm/helper.c +18
-0+ +if (el ==1 &&P ) { +return true; + }else if (el ==0 &&U ) { +return true; + } + +if (arm_feature (env,ARM_FEATURE_EL3 )) { +if (el ==1 && !secure &&NSK !=P ) { +return true; + }else if (el ==0 && !secure &&NSU !=U ) { +return true; + }else if (el ==3 && secure &&M !=P ) { +return true; + } + } + +if (arm_feature (env,ARM_FEATURE_EL2 ) && el ==2 && !secure && !NSH ) {
Quoted 8 lines
target/arm/helper.c static inline bool arm_ccnt_enabled(CPUARMState *env) · line 1051
Quoted 2 lines
target/arm/helper.c +2
-0+return true; + }This doesn't follow the structure that the Arm ARM pseudocode uses, which makes it a bit tricky to review. (see
AArch64.CountEvents()). It also doesn't implement the same logic -- for instance this code will return true if we're in NS EL1 and the U bit is set, whereas the pseudocode returns true for NS EL1 only if U != NSU.
Okay, I'll take another look at this logic.
Quoted 29 lines
Quoted 29 lines
target/arm/helper.c +7
-2+return false; +} +/* * Ensure c15_ccnt is the guest-visible count so that operations such as * enabling/disabling the counter or filtering, modifying the count itself, @@ -1023,7 +1070,8 @@ uint64_t pmccntr_op_start(CPUARMState *env) ARM_CPU_FREQ, NANOSECONDS_PER_SECOND);#endif -if (arm_ccnt_enabled (env)) { +if (arm_ccnt_enabled (env) && + !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {uint64_t eff_cycles = cycles;if (env->cp15.c9_pmcr &PMCRD ) {@@ -1043,7 +1091,8 @@ uint64_t pmccntr_op_start(CPUARMState *env)*/ void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) { -if (arm_ccnt_enabled (env)) { +if (arm_ccnt_enabled (env) && + !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {if (env->cp15.c9_pmcr &PMCRD ) {/* Increment once every 64 processor clock cycles */ @@ -1054,10 +1103,30 @@ void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles) } }
Quoted 7 lines
target/arm/helper.c void pmccntr_op_finish(CPUARMState *env, uint64_t prev_cycles) · line 1109
Quoted 4 lines
target/arm/helper.c +4
-0+uint64_t pmu_op_start (CPUARMState *env) +{ +return pmccntr_op_start (env); +}Do these two functions end up being different at the end of the patchset?
Yes.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 12/22] target/arm: Filter cycle counter based on PMCCFILTR_EL0
Quoted 19 lines · Aaron Lindsay
Quoted 17 lines · Peter Maydell
target/arm/cpu.h typedef struct CPUARMState { · line 465
Quoted 13 lines · Aaron Lindsay
target/arm/cpu.h +5
-0@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt; +/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;Can this ever hold valid state at a point when we need to do VM migration, or is it purely temporary ?
Quoted 4 lines
I believe that as of this version of the patch it is temporary and will not need to be migrated. However, I believe it's going to be necessary to have two variables to represent the state of each counter in order to implement interrupt on overflow.
Coming back around to this, I don't see a way around using two variables to hold PMCCNTR's full state to make interrupt on overflow work. I haven't been able to find other examples or documentation covering state needing to be updated in more than one location for a given CP register
- do you know of any I've missed or have recommendations about how to approach this?
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 12/22] target/arm: Filter cycle counter based on PMCCFILTR_EL0
Quoted 25 lines · Aaron Lindsay
Quoted 19 lines · Aaron Lindsay
Quoted 17 lines · Peter Maydell
target/arm/cpu.h typedef struct CPUARMState { · line 465
Quoted 13 lines · Aaron Lindsay
target/arm/cpu.h +5
-0@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt; +/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;Can this ever hold valid state at a point when we need to do VM migration, or is it purely temporary ?
Quoted 4 lines
I believe that as of this version of the patch it is temporary and will not need to be migrated. However, I believe it's going to be necessary to have two variables to represent the state of each counter in order to implement interrupt on overflow.
Quoted 6 lines
Coming back around to this, I don't see a way around using two variables to hold PMCCNTR's full state to make interrupt on overflow work. I haven't been able to find other examples or documentation covering state needing to be updated in more than one location for a given CP register
- do you know of any I've missed or have recommendations about how to approach this?
Can you explain the problem in more detail? In general it's a bit of a red flag if you think you need more state storage space than the hardware has, and I don't think there's any "hidden" state in the h/w here.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 12/22] target/arm: Filter cycle counter based on PMCCFILTR_EL0
Quoted 33 lines · Peter Maydell
Quoted 25 lines · Aaron Lindsay
Quoted 19 lines · Aaron Lindsay
Quoted 17 lines · Peter Maydell
target/arm/cpu.h typedef struct CPUARMState { · line 465
Quoted 13 lines · Aaron Lindsay
target/arm/cpu.h +5
-0@@ -458,6 +458,11 @@ typedef struct CPUARMState {* was reset. Otherwise it stores the counter value */ uint64_t c15_ccnt; +/* ccnt_cached_cycles is used to hold the last cycle count when +* c15_ccnt holds the guest-visible count instead of the delta during +* PMU operations which require this. +*/ +uint64_t ccnt_cached_cycles;Can this ever hold valid state at a point when we need to do VM migration, or is it purely temporary ?
Quoted 4 lines
I believe that as of this version of the patch it is temporary and will not need to be migrated. However, I believe it's going to be necessary to have two variables to represent the state of each counter in order to implement interrupt on overflow.
Quoted 6 lines
Coming back around to this, I don't see a way around using two variables to hold PMCCNTR's full state to make interrupt on overflow work. I haven't been able to find other examples or documentation covering state needing to be updated in more than one location for a given CP register
- do you know of any I've missed or have recommendations about how to approach this?
Quoted 3 lines
Can you explain the problem in more detail? In general it's a bit of a red flag if you think you need more state storage space than the hardware has, and I don't think there's any "hidden" state in the h/w here.
The critical difference between hardware and QEMU's PMU implementation is that hardware detects overflow when the overflow actually happens, which would be inefficient to do in software. Because QEMU stores a delta from the 'real' count (i.e. the clock/icount) and only updates the architectural counter values when necessary (when they're read/written), checking for overflow is less straightforward than checking if incrementing an individual counter by one flips the high-order bit from 1 to 0 as it happens. If the only information you have is the current counter value, and don't know how many events have occurred since you last checked or what the counter value was at that time, you can't tell whether or not it overflowed.
I haven't come up with a way to correctly and reliably detect overflow without storing additional information. I'll go ahead and post v4 with my first-pass implementation of the overflow code and see if you see something I'm missing or can think of a trick we can play to keep this inside of one register value.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 13/22 target/arm: Allow AArch32 access for PMCCFILTR
In reply to Aaron Lindsay--- target/arm/helper.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
target/arm/helper.c +26 -1
@@ -917,6 +917,10 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {#define PMXEVTYPER_MT 0x02000000#define PMXEVTYPER_EVTCOUNT 0x000003ff +#define PMCCFILTR 0xf8000000 +#define PMCCFILTR_M PMXEVTYPER_M +#define PMCCFILTR_EL0 (PMCCFILTR | PMCCFILTR_M) +#define PMU_NUM_COUNTERS (env) ((env->cp15.c9_pmcr & PMCRN_MASK) >> PMCRN_SHIFT)/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ #define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1))
@@ -1200,10 +1204,26 @@ static void pmccfiltr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) {uint64_t saved_cycles =pmccntr_op_start (env); - env->cp15.pmccfiltr_el0 = value &0xfc000000 ; + env->cp15.pmccfiltr_el0 = value &PMCCFILTR_EL0 ; +pmccntr_op_finish (env, saved_cycles); +} + +static void pmccfiltr_write_a32 (CPUARMState *env,const ARMCPRegInfo *ri, +uint64_t value) +{ +uint64_t saved_cycles =pmccntr_op_start (env); +/* M is not accessible from AArch32 */ + env->cp15.pmccfiltr_el0 = (env->cp15.pmccfiltr_el0 &PMCCFILTR_M ) | + (value &PMCCFILTR );pmccntr_op_finish (env, saved_cycles); } +static uint64_t pmccfiltr_read_a32 (CPUARMState *env,const ARMCPRegInfo *ri) +{ +/* M is not visible in AArch32 */ +return env->cp15.pmccfiltr_el0 &PMCCFILTR ; +} +static void pmcntenset_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {
@@ -1421,6 +1441,11 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .type = ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write, },#endif + { .name = "PMCCFILTR", .cp = 15, .opc1 = 0, .crn = 14, .crm = 15, .opc2 = 7, + .writefn = pmccfiltr_write_a32, .readfn = pmccfiltr_read_a32, + .access = PL0_RW, .accessfn = pmreg_access, + .type = ARM_CP_ALIAS | ARM_CP_IO, + .resetvalue = 0, }, { .name = "PMCCFILTR_EL0", .state = ARM_CP_STATE_AA64, .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 15, .opc2 = 7, .writefn = pmccfiltr_write,
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 14/22 target/arm: Make PMOVSCLR 64 bits wide
In reply to Aaron LindsayThis is a bug fix to ensure 64-bit reads of this register don't read adjacent data.
--- target/arm/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
target/arm/cpu.h +1 -1
@@ -367,7 +367,7 @@ typedef struct CPUARMState {uint32_t c9_data;uint64_t c9_pmcr;/* performance monitor control register */ uint64_t c9_pmcnten;/* perf monitor counter enables */ -uint32_t c9_pmovsr;/* perf monitor overflow status */ +uint64_t c9_pmovsr;/* perf monitor overflow status */ uint32_t c9_pmuserenr;/* perf monitor user enable */ uint64_t c9_pmselr;/* perf monitor counter selection register */ uint64_t c9_pminten;/* perf monitor interrupt enables */
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [PATCH v3 14/22] target/arm: Make PMOVSCLR 64 bits wide
Hi Aaron,
Quoted 13 lines · Aaron Lindsay
This is a bug fix to ensure 64-bit reads of this register don't read adjacent data.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/cpu.h +0
-0
target/arm/cpu.h typedef struct CPUARMState { · line 370
Quoted 5 lines
target/arm/cpu.h +1
-1@@ -367,7 +367,7 @@ typedef struct CPUARMState {uint32_t c9_data;uint64_t c9_pmcr;/* performance monitor control register */ uint64_t c9_pmcnten;/* perf monitor counter enables */ -uint32_t c9_pmovsr;/* perf monitor overflow status */ +uint64_t c9_pmovsr;/* perf monitor overflow status */
This doesn't look correct, since this reg is 32b.
I *think* the correct fix is in ARMCPRegInfo v7_cp_reginfo[]:
{ .name = "PMOVSR", ...- ..., .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr),
+ ..., .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr),
.accessfn = pmreg_access,
.writefn = pmovsr_write,
.raw_writefn = raw_write },
target/arm/cpu.h typedef struct CPUARMState { · line 373
Quoted 4 lines
target/arm/cpu.h +0
-0uint32_t c9_pmuserenr;/* perf monitor user enable */ uint64_t c9_pmselr;/* perf monitor counter selection register */ uint64_t c9_pminten;/* perf monitor interrupt enables */
Regards,
Phil.
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 14/22] target/arm: Make PMOVSCLR 64 bits wide
Phil,
Quoted 27 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 13 lines · Aaron Lindsay
This is a bug fix to ensure 64-bit reads of this register don't read adjacent data.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/cpu.h +0
-0target/arm/cpu.h typedef struct CPUARMState { · line 370
Quoted 5 lines
target/arm/cpu.h +1
-1@@ -367,7 +367,7 @@ typedef struct CPUARMState {uint32_t c9_data;uint64_t c9_pmcr;/* performance monitor control register */ uint64_t c9_pmcnten;/* perf monitor counter enables */ -uint32_t c9_pmovsr;/* perf monitor overflow status */ +uint64_t c9_pmovsr;/* perf monitor overflow status */ This doesn't look correct, since this reg is 32b.
I *think* the correct fix is in ARMCPRegInfo v7_cp_reginfo[]:
{ .name = "PMOVSR", ...
Review
Quoted 5 lines
(quoted diff) +1
-1- ..., .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + ..., .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr), .accessfn = pmreg_access, .writefn = pmovsr_write, .raw_writefn = raw_write },
Nearly all of these PMU registers are 32 bits wide, but most of them are implemented as 64-bit registers (PMCR, PMCNTEN*, PMSELR, PMINTEN* are a few examples I see in this patch's context). My understanding is that AArch64 register accesses are handled as 64 bits, even if the register itself isn't that wide (though I haven't personally verified this). See an earlier email from Peter from v2 of this patchset:
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03983.html
Does this still look wrong to you? If so, I'll take a more thorough look into how these accesses work.
Quoted 1 line
target/arm/cpu.h typedef struct CPUARMState { · line 371
Quoted 1 line
target/arm/cpu.h +0
-0uint32_t c9_pmuserenr;/* perf monitor user enable */
Whatever we decide should likely be done to PMUSERENR too - I think I overlooked this one before.
Quoted 7 lines
target/arm/cpu.h typedef struct CPUARMState { · line 373
Quoted 3 lines
target/arm/cpu.h +0
-0uint64_t c9_pmselr;/* perf monitor counter selection register */ uint64_t c9_pminten;/* perf monitor interrupt enables */ Regards,
Phil.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 14/22] target/arm: Make PMOVSCLR 64 bits wide
Quoted 36 lines · Aaron Lindsay
Phil,
Quoted 27 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 13 lines · Aaron Lindsay
This is a bug fix to ensure 64-bit reads of this register don't read adjacent data.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/cpu.h +0
-0target/arm/cpu.h typedef struct CPUARMState { · line 370
Quoted 5 lines
target/arm/cpu.h +1
-1@@ -367,7 +367,7 @@ typedef struct CPUARMState {uint32_t c9_data;uint64_t c9_pmcr;/* performance monitor control register */ uint64_t c9_pmcnten;/* perf monitor counter enables */ -uint32_t c9_pmovsr;/* perf monitor overflow status */ +uint64_t c9_pmovsr;/* perf monitor overflow status */ This doesn't look correct, since this reg is 32b.
I *think* the correct fix is in ARMCPRegInfo v7_cp_reginfo[]:
{ .name = "PMOVSR", ...Review
Quoted 5 lines
(quoted diff) +1
-1- ..., .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + ..., .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr), .accessfn = pmreg_access, .writefn = pmovsr_write, .raw_writefn = raw_write },
Quoted 5 lines
Nearly all of these PMU registers are 32 bits wide, but most of them are implemented as 64-bit registers (PMCR, PMCNTEN*, PMSELR, PMINTEN* are a few examples I see in this patch's context). My understanding is that AArch64 register accesses are handled as 64 bits, even if the register itself isn't that wide (though I haven't personally verified this).
Correct. Technically there's no such thing as a 32-bit wide AArch64 system register -- that is just a shorthand in the Arm ARM for "64-bit wide with the top 32-bits being RES0".
thanks
-- PMM
Re: [Qemu-arm] [Qemu-devel] [PATCH v3 14/22] target/arm: Make PMOVSCLR 64 bits wide
Quoted 43 lines · Peter Maydell
Quoted 36 lines · Aaron Lindsay
Phil,
Quoted 27 lines · Philippe Mathieu-Daudé
Hi Aaron,
Quoted 13 lines · Aaron Lindsay
This is a bug fix to ensure 64-bit reads of this register don't read adjacent data.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)target/arm/cpu.h +0
-0target/arm/cpu.h typedef struct CPUARMState { · line 370
Quoted 5 lines
target/arm/cpu.h +1
-1@@ -367,7 +367,7 @@ typedef struct CPUARMState {uint32_t c9_data;uint64_t c9_pmcr;/* performance monitor control register */ uint64_t c9_pmcnten;/* perf monitor counter enables */ -uint32_t c9_pmovsr;/* perf monitor overflow status */ +uint64_t c9_pmovsr;/* perf monitor overflow status */ This doesn't look correct, since this reg is 32b.
I *think* the correct fix is in ARMCPRegInfo v7_cp_reginfo[]:
{ .name = "PMOVSR", ...Review
Quoted 5 lines
(quoted diff) +1
-1- ..., .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + ..., .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr), .accessfn = pmreg_access, .writefn = pmovsr_write, .raw_writefn = raw_write },Quoted 5 lines
Nearly all of these PMU registers are 32 bits wide, but most of them are implemented as 64-bit registers (PMCR, PMCNTEN*, PMSELR, PMINTEN* are a few examples I see in this patch's context). My understanding is that AArch64 register accesses are handled as 64 bits, even if the register itself isn't that wide (though I haven't personally verified this).
Quoted 3 lines
Correct. Technically there's no such thing as a 32-bit wide AArch64 system register -- that is just a shorthand in the Arm ARM for "64-bit wide with the top 32-bits being RES0".
Ok, good to know. Thanks both for your explanation :)
Phil.
PATCH v3 15/22 target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
In reply to Aaron Lindsay--- target/arm/cpu.c | 3 +++ target/arm/cpu.h | 1 + 2 files changed, 4 insertions(+)
target/arm/cpu.c +3 -0
@@ -765,6 +765,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 ); +set_feature (env,ARM_FEATURE_V7VE );set_feature (env,ARM_FEATURE_ARM_DIV );set_feature (env,ARM_FEATURE_LPAE ); }
@@ -1481,6 +1482,7 @@ static void cortex_a7_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a7" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );
@@ -1526,6 +1528,7 @@ static void cortex_a15_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a15" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );
target/arm/cpu.h +1 -0
@@ -1439,6 +1439,7 @@ enum arm_features {ARM_FEATURE_OMAPCP ,/* OMAP specific CP15 ops handling. */ ARM_FEATURE_THUMB2EE ,ARM_FEATURE_V7MP ,/* v7 Multiprocessing Extensions */ +ARM_FEATURE_V7VE ,/* v7 with Virtualization Extensions */ ARM_FEATURE_V4T ,ARM_FEATURE_V5 , ARM_FEATURE_STRONGARM,
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 1 line · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>
Quoted 46 lines
--- target/arm/cpu.c | 3 +++ target/arm/cpu.h | 1 + 2 files changed, 4 insertions(+)target/arm/cpu.c +3
-0@@ -765,6 +765,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 ); +set_feature (env,ARM_FEATURE_V7VE );set_feature (env,ARM_FEATURE_ARM_DIV );set_feature (env,ARM_FEATURE_LPAE ); }@@ -1481,6 +1482,7 @@ static void cortex_a7_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a7" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );@@ -1526,6 +1528,7 @@ static void cortex_a15_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a15" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );target/arm/cpu.h +1
-0@@ -1439,6 +1439,7 @@ enum arm_features {ARM_FEATURE_OMAPCP ,/* OMAP specific CP15 ops handling. */ ARM_FEATURE_THUMB2EE ,ARM_FEATURE_V7MP ,/* v7 Multiprocessing Extensions */ +ARM_FEATURE_V7VE ,/* v7 with Virtualization Extensions */ ARM_FEATURE_V4T ,ARM_FEATURE_V5 , ARM_FEATURE_STRONGARM,
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
In reply to Aaron LindsayQuoted 39 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 3 +++ target/arm/cpu.h | 1 + 2 files changed, 4 insertions(+)target/arm/cpu.c +3
-0@@ -765,6 +765,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 ); +set_feature (env,ARM_FEATURE_V7VE );set_feature (env,ARM_FEATURE_ARM_DIV );set_feature (env,ARM_FEATURE_LPAE ); }@@ -1481,6 +1482,7 @@ static void cortex_a7_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a7" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );@@ -1526,6 +1528,7 @@ static void cortex_a15_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a15" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );target/arm/cpu.h +0
-0
target/arm/cpu.h enum arm_features { · line 1445
Quoted 7 lines
target/arm/cpu.h +1
-0@@ -1439,6 +1439,7 @@ enum arm_features {ARM_FEATURE_OMAPCP ,/* OMAP specific CP15 ops handling. */ ARM_FEATURE_THUMB2EE ,ARM_FEATURE_V7MP ,/* v7 Multiprocessing Extensions */ +ARM_FEATURE_V7VE ,/* v7 with Virtualization Extensions */ ARM_FEATURE_V4T ,ARM_FEATURE_V5 , ARM_FEATURE_STRONGARM,
What's the difference between this and ARM_FEATURE_EL2 ?
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 41 lines · Peter Maydell
Quoted 40 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/cpu.c | 3 +++ target/arm/cpu.h | 1 + 2 files changed, 4 insertions(+)target/arm/cpu.c +3
-0@@ -765,6 +765,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)/* Some features automatically imply others: */ if (arm_feature (env,ARM_FEATURE_V8 )) {set_feature (env,ARM_FEATURE_V7 ); +set_feature (env,ARM_FEATURE_V7VE );set_feature (env,ARM_FEATURE_ARM_DIV );set_feature (env,ARM_FEATURE_LPAE ); }@@ -1481,6 +1482,7 @@ static void cortex_a7_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a7" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );@@ -1526,6 +1528,7 @@ static void cortex_a15_initfn(Object *obj) cpu->dtb_compatible ="arm,cortex-a15" ;set_feature (&cpu->env,ARM_FEATURE_V7 ); +set_feature (&cpu->env,ARM_FEATURE_V7VE );set_feature (&cpu->env,ARM_FEATURE_VFP4 );set_feature (&cpu->env,ARM_FEATURE_NEON );set_feature (&cpu->env,ARM_FEATURE_THUMB2EE );target/arm/cpu.h +0
-0@@ -1439,6 +1439,7 @@ enum arm_features { ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
Quoted 8 lines
target/arm/cpu.h enum arm_features { · line 1445
Quoted 6 lines
target/arm/cpu.h +1
-0ARM_FEATURE_THUMB2EE ,ARM_FEATURE_V7MP ,/* v7 Multiprocessing Extensions */ +ARM_FEATURE_V7VE ,/* v7 with Virtualization Extensions */ ARM_FEATURE_V4T ,ARM_FEATURE_V5 , ARM_FEATURE_STRONGARM,What's the difference between this and
ARM_FEATURE_EL2?
I use ARM_FEATURE_V7VE in a later patch to guard against implementing PMOVSSET on v7 machines which don't implement the virtualization extensions
(http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04917.html).
I could use ARM_FEATURE_EL2, but declaring that v7 machines supported EL2 didn't feel right. I don't feel strongly one way or the other - how do you prefer to handle this?
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 10 lines · Aaron Lindsay
Quoted 1 line · Peter Maydell
What's the difference between this and
ARM_FEATURE_EL2?I use
ARM_FEATURE_V7VEin a later patch to guard against implementing PMOVSSET on v7 machines which don't implement the virtualization extensions
(http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04917.html).
I could useARM_FEATURE_EL2, but declaring that v7 machines supported EL2 didn't feel right. I don't feel strongly one way or the other - how do you prefer to handle this?
So, the underlying issue here is that there's a QEMU specific fudge going on. Architecturally, if the CPU implements the Virtualization Extensions, then:
* it has Hyp mode
* it must also implement the Security Extensions
* on reset it starts in the Secure world
* it has LPAE
* it has some stuff that is not inherently tied to having EL2, like the SDIV and UDIV instructions, and the presence of PMOVSSET
In an ideal world, we'd just have a feature flag that turned all that on. Unfortunately, a combination of backwards compatibility issues, the order in which various features were implemented in QEMU, and the fact that KVM can't emulate a guest CPU with the Security Extensions means that we want to be able to model variants of some CPUs that don't really exist in real hardware:
Cortex-A15 and -A7 which only implement EL0/EL1 but still have all the v7VE features that you can see from those ELs. But we didn't really properly lay out guidelines for how the feature bits should work in this case, with the result that we have a bunch of local hacks (for instance get_S1prot() has a check on the LPAE feature bit, since in practice that bit is set in exactly the CPUs that have v7VE; and the UDIV/SDIV insns have their own feature bits.)
So we should probably sort out this mess first, either by:
(a) state that we use ARM_FEATURE_LPAE for all checks for features that are architecturally v7VE but which we want to exist even on our v7VE-no-Hyp-no-Secure oddballs
(b) define an ARM_FEATURE_V7VE for them
(c) define separate feature bits for them individually
In any case we'd retain ARM_FEATURE_EL2 for "and really has EL2/Hyp mode", and we'd want to do an audit of current uses of various feature bits to see whether they followed the new rules.
(For AArch64 things are a bit less awkward because the architecture allows the idea of an implementation that has EL2 but not EL3.)
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 38 lines · Peter Maydell
Quoted 10 lines · Aaron Lindsay
Quoted 1 line · Peter Maydell
What's the difference between this and
ARM_FEATURE_EL2?I use
ARM_FEATURE_V7VEin a later patch to guard against implementing PMOVSSET on v7 machines which don't implement the virtualization extensions
(http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04917.html).
I could useARM_FEATURE_EL2, but declaring that v7 machines supported EL2 didn't feel right. I don't feel strongly one way or the other - how do you prefer to handle this?So, the underlying issue here is that there's a QEMU specific fudge going on. Architecturally, if the CPU implements the Virtualization Extensions, then:
* it has Hyp mode
* it must also implement the Security Extensions
* on reset it starts in the Secure world
* it has LPAE
* it has some stuff that is not inherently tied to having EL2, like the SDIV and UDIV instructions, and the presence of PMOVSSETIn an ideal world, we'd just have a feature flag that turned all that on. Unfortunately, a combination of backwards compatibility issues, the order in which various features were implemented in QEMU, and the fact that KVM can't emulate a guest CPU with the Security Extensions means that we want to be able to model variants of some CPUs that don't really exist in real hardware:
Cortex-A15 and -A7 which only implement EL0/EL1 but still have all the v7VE features that you can see from those ELs. But we didn't really properly lay out guidelines for how the feature bits should work in this case, with the result that we have a bunch of local hacks (for instanceget_S1prot()has a check on the LPAE feature bit, since in practice that bit is set in exactly the CPUs that have v7VE; and the UDIV/SDIV insns have their own feature bits.)
Quoted 5 lines
So we should probably sort out this mess first, either by:
(a) state that we use
ARM_FEATURE_LPAEfor all checks for features that are architecturally v7VE but which we want to exist even on our v7VE-no-Hyp-no-Secure oddballs
Are you implying that this would only involve updating the comments to match the existing implementation?
Quoted 1 line
(b) define an
ARM_FEATURE_V7VEfor them
This seems the most attractive to me, though perhaps that's partially aspirational - it is closest to what would be happening in an ideal world where QEMU fully supported V7VE for this hardware.
Quoted 1 line
(c) define separate feature bits for them individually
I'm hesitant to formulate a patch for this - I'm not confident I understand the context and interactions of the pieces involved well enough to contribute productively. That said, I understand your motivation to fix this the right way and am willing to try with a little more direction/hand-holding.
For instance, which CPUs are we talking about here - I only see both ARM_FEATURE_ARM_DIV and ARM_FEATURE_LPAE advertised together (without full V8) in cortex_a7_initfn and cortex_a15_initfn. I'm assuming that V8 implies the full set of V7VE features we're discussing here so whatever we come up with as a solution would be automatically set in the ARM_FEATURE_V8 "Some features automatically imply others:" if statement in arm_cpu_realizefn.
-Aaron
Quoted 8 lines
In any case we'd retain
ARM_FEATURE_EL2for "and really has EL2/Hyp mode", and we'd want to do an audit of current uses of various feature bits to see whether they followed the new rules.(For AArch64 things are a bit less awkward because the architecture allows the idea of an implementation that has EL2 but not EL3.)
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
In reply to Peter MaydellQuoted 40 lines · Peter Maydell
Quoted 10 lines · Aaron Lindsay
Quoted 1 line · Peter Maydell
What's the difference between this and
ARM_FEATURE_EL2?I use
ARM_FEATURE_V7VEin a later patch to guard against implementing PMOVSSET on v7 machines which don't implement the virtualization extensions
(http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04917.html).
I could useARM_FEATURE_EL2, but declaring that v7 machines supported EL2 didn't feel right. I don't feel strongly one way or the other - how do you prefer to handle this?So, the underlying issue here is that there's a QEMU specific fudge going on. Architecturally, if the CPU implements the Virtualization Extensions, then:
* it has Hyp mode
* it must also implement the Security Extensions
* on reset it starts in the Secure world
* it has LPAE
* it has some stuff that is not inherently tied to having EL2, like the SDIV and UDIV instructions, and the presence of PMOVSSETIn an ideal world, we'd just have a feature flag that turned all that on. Unfortunately, a combination of backwards compatibility issues, the order in which various features were implemented in QEMU, and the fact that KVM can't emulate a guest CPU with the Security Extensions means that we want to be able to model variants of some CPUs that don't really exist in real hardware:
Cortex-A15 and -A7 which only implement EL0/EL1 but still have all the v7VE features that you can see from those ELs. But we didn't really properly lay out guidelines for how the feature bits should work in this case, with the result that we have a bunch of local hacks (for instanceget_S1prot()has a check on the LPAE feature bit, since in practice that bit is set in exactly the CPUs that have v7VE; and the UDIV/SDIV insns have their own feature bits.)So we should probably sort out this mess first, either by:
Quoted 7 lines
(a) state that we use
ARM_FEATURE_LPAEfor all checks for features that are architecturally v7VE but which we want to exist even on our v7VE-no-Hyp-no-Secure oddballs
(b) define anARM_FEATURE_V7VEfor them
(c) define separate feature bits for them individuallyFrom what I can tell, using
ARM_FEATURE_LPAEto represent all the
almost-v7ve misfits won't work well because ARM_FEATURE_ARM_DIV may be supported on some platforms for which ARM_FEATURE_LPAE is not (Cortex R5), and ARM_FEATURE_ARM_DIV is read from ID_ISAR0 in kvm_arm_get_host_cpu_features() (and may be set/not set independently of ARM_FEATURE_LPAE). It appears there is a need to independently distinguish between them. The same reasoning also seems to rule out option (b) "one ARM_FEATURE_V7VE to rule them all", leaving me with option (c).
It almost seems silly to create ARM_FEATURE_PMOVSSET, but I'm not sure what else makes sense to do here. Am I missing something (I'm almost hoping I am)?
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 35 lines · Aaron Lindsay
Quoted 26 lines · Peter Maydell
So, the underlying issue here is that there's a QEMU specific fudge going on. Architecturally, if the CPU implements the Virtualization Extensions, then:
* it has Hyp mode
* it must also implement the Security Extensions
* on reset it starts in the Secure world
* it has LPAE
* it has some stuff that is not inherently tied to having EL2, like the SDIV and UDIV instructions, and the presence of PMOVSSETIn an ideal world, we'd just have a feature flag that turned all that on. Unfortunately, a combination of backwards compatibility issues, the order in which various features were implemented in QEMU, and the fact that KVM can't emulate a guest CPU with the Security Extensions means that we want to be able to model variants of some CPUs that don't really exist in real hardware:
Cortex-A15 and -A7 which only implement EL0/EL1 but still have all the v7VE features that you can see from those ELs. But we didn't really properly lay out guidelines for how the feature bits should work in this case, with the result that we have a bunch of local hacks (for instanceget_S1prot()has a check on the LPAE feature bit, since in practice that bit is set in exactly the CPUs that have v7VE; and the UDIV/SDIV insns have their own feature bits.)Quoted 7 lines
So we should probably sort out this mess first, either by:
(a) state that we use
ARM_FEATURE_LPAEfor all checks for features that are architecturally v7VE but which we want to exist even on our v7VE-no-Hyp-no-Secure oddballs
(b) define anARM_FEATURE_V7VEfor them
(c) define separate feature bits for them individually
Quoted 7 lines
From what I can tell, using
ARM_FEATURE_LPAEto represent all the almost-v7ve misfits won't work well becauseARM_FEATURE_ARM_DIVmay be supported on some platforms for whichARM_FEATURE_LPAEis not (Cortex R5), andARM_FEATURE_ARM_DIVis read fromID_ISAR0inkvm_arm_get_host_cpu_features()(and may be set/not set independently ofARM_FEATURE_LPAE). It appears there is a need to independently distinguish between them.
We need (and already have) a separate feature bit for ARM_DIV exactly because it's present on some CPUs which don't have V7VE; so we don't want to roll that back into a V7VE feature bit.
Quoted 7 lines
The same reasoning also seems to rule out
option (b) "oneARM_FEATURE_V7VEto rule them all", leaving me with option (c).It almost seems silly to create
ARM_FEATURE_PMOVSSET, but I'm not sure what else makes sense to do here. Am I missing something (I'm almost hoping I am)?
Sorry, I forgot I hadn't replied to this email yet. Let's do this:
* define a new ARM_FEATURE_V7VE:
ARM_FEATURE_V7VE, /* v7 Virtualization Extensions (non-EL2 parts) */
In arm_cpu_realizefn:
* change the existing "FEATURE_V8 implies V7/ARM_DIV/LPAE" to "FEATURE_V8 implies V7VE"
* below that put
if (arm_feature(env, ARM_FEATURE_V7VE) {
/* v7 Virtualization Extensions. In real hardware this implies
* EL2 and also the presence of the Security Extensions.
* For QEMU, for backwards-compatibility we implement some
* CPUs or CPU configs which have no actual EL2 or EL3 but do
* include the various other features that V7VE implies.
* Presence of EL2 itself is ARM_FEATURE_EL2, and of the
* Security Extensions is ARM_FEATURE_EL3.
*/
set_feature(env, ARM_FEATURE_ARM_DIV); set_feature(env, ARM_FEATURE_LPAE); set_feature(env, ARM_FEATURE_V7);
}
* in kvm_arm_get_host_cpu_features() in kvm32.c add set_feature(&features, ARM_FEATURE_V7VE); where we currently set V7, LPAE, etc.
(by definition a host CPU which supports KVM has v7VE.)
* perhaps some followon patches that correct checks that were testing something else and can now use the new V7VE feature bit.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 52 lines · Peter Maydell
Quoted 35 lines · Aaron Lindsay
Quoted 26 lines · Peter Maydell
So, the underlying issue here is that there's a QEMU specific fudge going on. Architecturally, if the CPU implements the Virtualization Extensions, then:
* it has Hyp mode
* it must also implement the Security Extensions
* on reset it starts in the Secure world
* it has LPAE
* it has some stuff that is not inherently tied to having EL2, like the SDIV and UDIV instructions, and the presence of PMOVSSETIn an ideal world, we'd just have a feature flag that turned all that on. Unfortunately, a combination of backwards compatibility issues, the order in which various features were implemented in QEMU, and the fact that KVM can't emulate a guest CPU with the Security Extensions means that we want to be able to model variants of some CPUs that don't really exist in real hardware:
Cortex-A15 and -A7 which only implement EL0/EL1 but still have all the v7VE features that you can see from those ELs. But we didn't really properly lay out guidelines for how the feature bits should work in this case, with the result that we have a bunch of local hacks (for instanceget_S1prot()has a check on the LPAE feature bit, since in practice that bit is set in exactly the CPUs that have v7VE; and the UDIV/SDIV insns have their own feature bits.)Quoted 7 lines
So we should probably sort out this mess first, either by:
(a) state that we use
ARM_FEATURE_LPAEfor all checks for features that are architecturally v7VE but which we want to exist even on our v7VE-no-Hyp-no-Secure oddballs
(b) define anARM_FEATURE_V7VEfor them
(c) define separate feature bits for them individuallyQuoted 7 lines
From what I can tell, using
ARM_FEATURE_LPAEto represent all the almost-v7ve misfits won't work well becauseARM_FEATURE_ARM_DIVmay be supported on some platforms for whichARM_FEATURE_LPAEis not (Cortex R5), andARM_FEATURE_ARM_DIVis read fromID_ISAR0inkvm_arm_get_host_cpu_features()(and may be set/not set independently ofARM_FEATURE_LPAE). It appears there is a need to independently distinguish between them.We need (and already have) a separate feature bit for
ARM_DIVexactly because it's present on some CPUs which don't have V7VE; so we don't want to roll that back into a V7VE feature bit.Quoted 4 lines
The same reasoning also seems to rule out
option (b) "oneARM_FEATURE_V7VEto rule them all", leaving me with option (c).
Quoted 5 lines
Quoted 3 lines
It almost seems silly to create
ARM_FEATURE_PMOVSSET, but I'm not sure what else makes sense to do here. Am I missing something (I'm almost hoping I am)?Sorry, I forgot I hadn't replied to this email yet. Let's do this:
No problem at all - to be fair, my responses have been a bit sporadic, too. I'm working on putting your suggestions into patch form, with one clarification below. I also believe I owe you a response on another thread or two before I push out the next version of this patchset.
Quoted 11 lines
* define a new
ARM_FEATURE_V7VE:
ARM_FEATURE_V7VE, /* v7 Virtualization Extensions (non-EL2 parts) */In
arm_cpu_realizefn:* change the existing "
FEATURE_V8implies V7/ARM_DIV/LPAE" to "FEATURE_V8implies V7VE"
* below that put
Quoted 10 lines
if (
arm_feature(env, ARM_FEATURE_V7VE){
/* v7 Virtualization Extensions. In real hardware this implies
* EL2 and also the presence of the Security Extensions.
* For QEMU, for backwards-compatibility we implement some
* CPUs or CPU configs which have no actual EL2 or EL3 but do
* include the various other features that V7VE implies.
* Presence of EL2 itself isARM_FEATURE_EL2, and of the
* Security Extensions isARM_FEATURE_EL3.
*/
set_feature(env, ARM_FEATURE_ARM_DIV);
Is it safe to assume from your comment above regarding keeping ARM_DIV separate from V7VE that the inclusion of it here is an oversight and that only LPAE and V7 should be set if V7VE is? (and that V8 should now directly imply both V7VE and ARM_DIV?)
Quoted 8 lines
set_feature(env, ARM_FEATURE_LPAE); set_feature(env, ARM_FEATURE_V7);}
* in
kvm_arm_get_host_cpu_features()inkvm32.caddset_feature(&features, ARM_FEATURE_V7VE); where we currently set V7, LPAE, etc.
(by definition a host CPU which supports KVM has v7VE.)
Thanks!
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 12 lines · Aaron Lindsay
Quoted 10 lines · Peter Maydell
if (
arm_feature(env, ARM_FEATURE_V7VE){
/* v7 Virtualization Extensions. In real hardware this implies
* EL2 and also the presence of the Security Extensions.
* For QEMU, for backwards-compatibility we implement some
* CPUs or CPU configs which have no actual EL2 or EL3 but do
* include the various other features that V7VE implies.
* Presence of EL2 itself isARM_FEATURE_EL2, and of the
* Security Extensions isARM_FEATURE_EL3.
*/
set_feature(env, ARM_FEATURE_ARM_DIV);
Quoted 4 lines
Is it safe to assume from your comment above regarding keeping
ARM_DIVseparate from V7VE that the inclusion of it here is an oversight and that only LPAE and V7 should be set if V7VE is? (and that V8 should now directly imply both V7VE andARM_DIV?)
No; V7VE always implies ARM_DIV. (ARM_DIV doesn't imply V7VE, though, which is why it is a separate feature bit.)
thanks
-- PMM
Re: [Qemu-devel] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 13 lines · Peter Maydell
Quoted 12 lines · Aaron Lindsay
Quoted 10 lines · Peter Maydell
if (
arm_feature(env, ARM_FEATURE_V7VE){
/* v7 Virtualization Extensions. In real hardware this implies
* EL2 and also the presence of the Security Extensions.
* For QEMU, for backwards-compatibility we implement some
* CPUs or CPU configs which have no actual EL2 or EL3 but do
* include the various other features that V7VE implies.
* Presence of EL2 itself isARM_FEATURE_EL2, and of the
* Security Extensions isARM_FEATURE_EL3.
*/
set_feature(env, ARM_FEATURE_ARM_DIV);
Quoted 7 lines
Quoted 4 lines
Is it safe to assume from your comment above regarding keeping
ARM_DIVseparate from V7VE that the inclusion of it here is an oversight and that only LPAE and V7 should be set if V7VE is? (and that V8 should now directly imply both V7VE andARM_DIV?)No; V7VE always implies
ARM_DIV. (ARM_DIVdoesn't imply V7VE, though, which is why it is a separate feature bit.)
Okay, then I'm confused about some of the preexisting logic in kvm_arm_get_host_cpu_features. The preexisting code in that function sets ARM_DIV and THUMB_DIV based on the appropriate bits in ID_ISAR0. If we already knew that
Quoted 1 line
(by definition a host CPU which supports KVM has v7VE.)
and that all V7VE CPUs have ARM_DIV, why did the code there bother checking ID_ISAR0 to begin with?
Quoted 11 lines
switch (
extract32(id_isar0, 24, 4)) {
case 1:set_feature(&features, ARM_FEATURE_THUMB_DIV); break; case 2: set_feature(&features, ARM_FEATURE_ARM_DIV); set_feature(&features, ARM_FEATURE_THUMB_DIV); break; default: break; }
Should this switch/case be removed entirely?
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 11 lines · Aaron Lindsay
Quoted 2 lines · Peter Maydell
No; V7VE always implies
ARM_DIV. (ARM_DIVdoesn't imply V7VE, though, which is why it is a separate feature bit.)Okay, then I'm confused about some of the preexisting logic in
kvm_arm_get_host_cpu_features. The preexisting code in that function setsARM_DIVandTHUMB_DIVbased on the appropriate bits inID_ISAR0. If we already knew thatQuoted 1 line
(by definition a host CPU which supports KVM has v7VE.)
and that all V7VE CPUs have
ARM_DIV, why did the code there bother checkingID_ISAR0to begin with?
Good question. I suspect I'd just forgotten that at the point when I wrote that KVM code.
Quoted 12 lines
Quoted 11 lines
switch (
extract32(id_isar0, 24, 4)) {
case 1:set_feature(&features, ARM_FEATURE_THUMB_DIV); break; case 2: set_feature(&features, ARM_FEATURE_ARM_DIV); set_feature(&features, ARM_FEATURE_THUMB_DIV); break; default: break; }
Quoted 1 line
Should this switch/case be removed entirely?
Yes, I think so (and also the id_isar0 variable and the idregs[] entry which arranges to initialize it). We should just set the THUMB_DIV and ARM_DIV features explicitly.
thanks
-- PMM
Re: [Qemu-arm] [PATCH v3 15/22] target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions
Quoted 13 lines · Peter Maydell
Quoted 12 lines · Aaron Lindsay
Quoted 11 lines
switch (
extract32(id_isar0, 24, 4)) {
case 1:set_feature(&features, ARM_FEATURE_THUMB_DIV); break; case 2: set_feature(&features, ARM_FEATURE_ARM_DIV); set_feature(&features, ARM_FEATURE_THUMB_DIV); break; default: break; }
Quoted 5 lines
Quoted 1 line
Should this switch/case be removed entirely?
Yes, I think so (and also the
id_isar0variable and the idregs[] entry which arranges to initialize it). We should just set theTHUMB_DIVandARM_DIVfeatures explicitly.
Okay, thanks for straightening me out! I sensed there was some inconsistency, but misjudged exactly where. I'll include this change in my next patchset.
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 16/22 target/arm: Implement PMOVSSET
In reply to Aaron LindsayAdding an array for v7VE+ CP registers was necessary so that PMOVSSET wasn't defined for all v7 processors.
--- target/arm/helper.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)
target/arm/helper.c +31 -1
@@ -1241,9 +1241,17 @@ static void pmcntenclr_write(CPUARMState *env, const ARMCPRegInfo *ri,static void pmovsr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pmovsr &= ~value; } +static void pmovsset_write (CPUARMState *env,const ARMCPRegInfo *ri, +uint64_t value) +{ + value &=PMU_COUNTER_MASK (env); + env->cp15.c9_pmovsr |= value; +} +static void pmxevtyper_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {
@@ -1406,7 +1414,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmcnten), .writefn = pmcntenclr_write }, { .name = "PMOVSR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 3, - .access = PL0_RW, .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + .access = PL0_RW, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr), .accessfn = pmreg_access, .writefn = pmovsr_write, .raw_writefn = raw_write },
@@ -1592,6 +1600,25 @@ static const ARMCPRegInfo v7mp_cp_reginfo[] = {REGINFO_SENTINEL }; +static const ARMCPRegInfo v7ve_cp_reginfo[] = { +/* Performance monitor registers which are not implemented in v7 before +* v7ve: +*/ + { .name ="PMOVSSET" , .cp =15 , .opc1 =0 , .crn =9 , .crm =14 , .opc2 =3 , + .access =PL0_RW , .accessfn = pmreg_access, + .fieldoffset =offsetoflow32 (CPUARMState, cp15.c9_pmovsr), + .writefn = pmovsset_write, + .raw_writefn = raw_write }, + { .name ="PMOVSSET_EL0" , .state =ARM_CP_STATE_AA64 , + .opc0 =3 , .opc1 =3 , .crn =9 , .crm =14 , .opc2 =3 , + .access =PL0_RW , .accessfn = pmreg_access, + .type =ARM_CP_ALIAS , + .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + .writefn = pmovsset_write, + .raw_writefn = raw_write }, +REGINFO_SENTINEL +}; +static void teecr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {
@@ -4943,6 +4970,9 @@ void register_cp_regs_for_features(ARMCPU *cpu) !arm_feature(env, ARM_FEATURE_PMSA)) {define_arm_cp_regs (cpu, v7mp_cp_reginfo); } +if (arm_feature (env,ARM_FEATURE_V7VE )) { +define_arm_cp_regs (cpu, v7ve_cp_reginfo); + }if (arm_feature (env,ARM_FEATURE_V7 )) {/* v7 performance monitor control register: same implementor * field as main ID register, and we implement only the cycle
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 16/22] target/arm: Implement PMOVSSET
Quoted 31 lines · Aaron Lindsay
Adding an array for v7VE+ CP registers was necessary so that PMOVSSET wasn't defined for all v7 processors.
Signed-off-by Aaron Lindsay <[email protected]>--- target/arm/helper.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)target/arm/helper.c +8
-0@@ -1241,9 +1241,17 @@ static void pmcntenclr_write(CPUARMState *env, const ARMCPRegInfo *ri,static void pmovsr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) { + value &=PMU_COUNTER_MASK (env); env->cp15.c9_pmovsr &= ~value; } +static void pmovsset_write (CPUARMState *env,const ARMCPRegInfo *ri, +uint64_t value) +{ + value &=PMU_COUNTER_MASK (env); + env->cp15.c9_pmovsr |= value; +} +static void pmxevtyper_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {
target/arm/helper.c static const ARMCPRegInfo v7_cp_reginfo[] = { · line 1420
Quoted 8 lines
target/arm/helper.c +1
-1@@ -1406,7 +1414,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmcnten), .writefn = pmcntenclr_write }, { .name = "PMOVSR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 3, - .access = PL0_RW, .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), + .access = PL0_RW, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr), .accessfn = pmreg_access, .writefn = pmovsr_write, .raw_writefn = raw_write },
This change is half of a bug fix (the other half being to make the field in the CPU struct be uint64_t rather than uint32_t). That bug fix should be in a patch of its own.
pmuserenr has the same bug (uint32_t state field accessed by a STATE_AA64 sysreg).
thanks
-- PMM
PATCH v3 17/22 target/arm: Split arm_ccnt_enabled into generic pmu_counter_enabled
In reply to Aaron Lindsay--- target/arm/helper.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
target/arm/helper.c +8 -3
@@ -1009,17 +1009,22 @@ static CPAccessResult pmreg_access_ccntr(CPUARMState *env,return pmreg_access (env, ri, isread); } -static inline bool arm_ccnt_enabled (CPUARMState *env) +static inline bool pmu_counter_enabled (CPUARMState *env,uint8_t counter) {/* Does not check PMCCFILTR_EL0, which is handled by pmu_counter_filtered */ - -if (!(env->cp15.c9_pmcr &PMCRE ) || !(env->cp15.c9_pmcnten & (1 <<31 ))) { +if (!(env->cp15.c9_pmcr &PMCRE ) || + !(env->cp15.c9_pmcnten & (1 << counter))) {return false; }return true; } +static inline bool arm_ccnt_enabled (CPUARMState *env) +{ +return pmu_counter_enabled (env,31 ); +} +/* Returns true if the counter corresponding to the passed-in pmevtyper or * pmccfiltr value is filtered using the current state */ static inline bool pmu_counter_filtered (CPUARMState *env,uint64_t pmxevtyper)
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-arm] [PATCH v3 17/22] target/arm: Split arm_ccnt_enabled into generic pmu_counter_enabled
Quoted 22 lines · Aaron Lindsay
Signed-off-by Aaron Lindsay <[email protected]>Reviewed-by Peter Maydell <[email protected]>--- target/arm/helper.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)target/arm/helper.c +3
-3@@ -1009,17 +1009,22 @@ static CPAccessResult pmreg_access_ccntr(CPUARMState *env,return pmreg_access (env, ri, isread); } -static inline bool arm_ccnt_enabled (CPUARMState *env) +static inline bool pmu_counter_enabled (CPUARMState *env,uint8_t counter) {/* Does not check PMCCFILTR_EL0, which is handled by pmu_counter_filtered */ - -if (!(env->cp15.c9_pmcr &PMCRE ) || !(env->cp15.c9_pmcnten & (1 <<31 ))) { +if (!(env->cp15.c9_pmcr &PMCRE ) || + !(env->cp15.c9_pmcnten & (1 << counter))) {
target/arm/helper.c static CPAccessResult pmreg_access_ccntr(CPUARMState *env, · line 1026
Quoted 10 lines
target/arm/helper.c +4
-0return false; }return true; } +static inline bool arm_ccnt_enabled (CPUARMState *env) +{ +return pmu_counter_enabled (env,31 ); +}
We only use arm_ccnt_enabled() in a couple of places, so I would just make those callsites use pmu_counter_enabled(env, 31) directly.
thanks
-- PMM
PATCH v3 18/22 target/arm: Add array for supported PMU events, generate PMCEID[01]
In reply to Aaron LindsayThis commit doesn't add any supported events, but provides the framework for adding them. We store the pm_event structs in a simple array, and provide the mapping from the event numbers to array indexes in the supported_event_map array.
--- target/arm/cpu.c | 4 ++++ target/arm/cpu.h | 10 ++++++++++ target/arm/helper.c | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 51 insertions(+)
target/arm/cpu.c +4 -0
@@ -889,6 +889,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)unset_feature (env,ARM_FEATURE_PMU ); cpu->id_aa64dfr0 &= ~0xf00 ; }else { +uint64_t pmceid =get_pmceid (&cpu->env); + cpu->pmceid0 = pmceid &0xffffffff ; + cpu->pmceid1 = (pmceid >>32 ) &0xffffffff ; +arm_register_pre_el_change_hook (cpu, &pmu_pre_el_change,0 );arm_register_el_change_hook (cpu, &pmu_post_el_change,0 ); }
target/arm/cpu.h +10 -0
@@ -931,6 +931,16 @@ void pmu_op_finish(CPUARMState *env, uint64_t prev_cycles);void pmu_pre_el_change (ARMCPU *cpu,void *ignored);void pmu_post_el_change (ARMCPU *cpu,void *ignored); +/* +* get_pmceid +* @env: CPUARMState +* +* Return the PMCEID[01] register values corresponding to the counters which +* are supported given the current configuration (0 is low 32, 1 is high 32 +* bits) +*/ +uint64_t get_pmceid (CPUARMState *env); +/* SCTLR bit meanings. Several bits have been reused in newer * versions of the architecture; in that case we define constants * for both old and new bit meanings. Code which tests against those
target/arm/helper.c +37 -0
@@ -925,6 +925,43 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {/* Bits allowed to be set/cleared for PMCNTEN* and PMINTEN* */ #define PMU_COUNTER_MASK (env) ((1 << 31) | ((1 << PMU_NUM_COUNTERS(env)) - 1)) +typedef struct pm_event { +uint16_t number;/* PMEVTYPER.evtCount is 10 bits wide */ +/* If the event is supported on this CPU (used to generate PMCEID[01]) */ +bool (*supported)(CPUARMState *); +/* Retrieve the current count of the underlying event. The programmed +* counters hold a difference from the return value from this function */ +uint64_t (*get_count)(CPUARMState *); +}pm_event ; + +#define SUPPORTED_EVENT_SENTINEL UINT16_MAX +static const pm_event pm_events[] = { + { .number =SUPPORTED_EVENT_SENTINEL } +}; +static uint16_t supported_event_map[0x3f ]; + +/* +* Called upon initialization to build PMCEID0 (low 32 bits) and PMCEID1 (high +* 32). We also use it to build a map of ARM event numbers to indices in +* our pm_events array. +*/ +uint64_t get_pmceid (CPUARMState *env) +{ +uint64_t pmceid =0 ; +unsigned int i =0 ; +while (pm_events[i].number !=SUPPORTED_EVENT_SENTINEL ) { +const pm_event *cnt = &pm_events[i]; +if (cnt->number <0x3f && cnt->supported (env)) { + pmceid |= (1 << cnt->number); + supported_event_map[cnt->number] = i; + }else { + supported_event_map[cnt->number] =SUPPORTED_EVENT_SENTINEL ; + } + i++; + } +return pmceid; +} +static CPAccessResult pmreg_access (CPUARMState *env,const ARMCPRegInfo *ri,bool isread) {
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 19/22 target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER
In reply to Aaron LindsayAdd arrays to hold the registers, the definitions themselves, access functions, and add logic to reset counters when PMCR.P is set.
--- target/arm/cpu.h | 7 +- target/arm/helper.c | 219 ++++++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 207 insertions(+), 19 deletions(-)
target/arm/cpu.h +5 -2
@@ -454,8 +454,9 @@ typedef struct CPUARMState {uint64_t oslsr_el1;/* OS Lock Status */ uint64_t mdcr_el2;uint64_t mdcr_el3; -/* If the counter is enabled, this stores the last time the counter -* was reset. Otherwise it stores the counter value +/* If the pmccntr and pmevcntr counters are enabled, they store the +* offset the last time the counter was reset. Otherwise they store the +* counter value. */ uint64_t c15_ccnt;/* ccnt_cached_cycles is used to hold the last cycle count when
@@ -463,6 +464,8 @@ typedef struct CPUARMState {* PMU operations which require this. */ uint64_t ccnt_cached_cycles; +uint64_t c14_pmevcntr[31 ]; +uint64_t c14_pmevtyper[31 ];uint64_t pmccfiltr_el0;/* Performance Monitor Filter Register */ uint64_t vpidr_el2;/* Virtualization Processor ID Register */ uint64_t vmpidr_el2;/* Virtualization Multiprocessor ID Register */
target/arm/helper.c +202 -17
306 lines not on this page · raw message
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 20/22 target/arm: PMU: Add instruction and cycle events
In reply to Aaron LindsayThe instruction event is only enabled when icount is used, cycles are always supported. Always defining get_cycle_count (but altering its behavior depending on CONFIG_USER_ONLY) allows us to remove some CONFIG_USER_ONLY #defines throughout the rest of the code.
--- target/arm/helper.c | 99 ++++++++++++++++++++++++++++------------------------- 1 file changed, 52 insertions(+), 47 deletions(-)
target/arm/helper.c +52 -47
@@ -15,6 +15,7 @@#include "arm_ldst.h" #include <zlib.h> /* For crc32 */ #include "exec/semihost.h" +#include "sysemu/cpus.h" #include "sysemu/kvm.h" #include "fpu/softfloat.h"
@@ -935,8 +936,54 @@ typedef struct pm_event {uint64_t (*get_count)(CPUARMState *,uint64_t cycles); } pm_event; +/* +* Return the underlying cycle count for the PMU cycle counters. If we're in +* usermode, simply return 0. +*/ +static uint64_t get_cycle_count (CPUARMState *env) +{ +#ifndef CONFIG_USER_ONLY +return muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), +ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); +#else +return 0 ; +#endif +} + +static bool event_always_supported (CPUARMState *env) +{ +return true; +} + +#ifndef CONFIG_USER_ONLY +static uint64_t cycles_get_count (CPUARMState *env,uint64_t cycles) +{ +return cycles; +} + +static bool instructions_supported (CPUARMState *env) +{ +return use_icount ==1 /* Precise instruction counting */ ; +} + +static uint64_t instructions_get_count (CPUARMState *env,uint64_t cycles) +{ +return (uint64_t )cpu_get_icount_raw (); +} +#endif +#define SUPPORTED_EVENT_SENTINEL UINT16_MAXstatic const pm_event pm_events[] = { +#ifndef CONFIG_USER_ONLY + { .number =0x008 ,/* INST_RETIRED */ + .supported = instructions_supported, + .get_count = instructions_get_count + }, + { .number =0x011 ,/* CPU_CYCLES */ + .supported = event_always_supported, + .get_count = cycles_get_count + }, +#endif { .number =SUPPORTED_EVENT_SENTINEL } };static uint16_t supported_event_map[0x3f ];
@@ -1016,8 +1063,6 @@ static CPAccessResult pmreg_access_swinc(CPUARMState *env,return pmreg_access (env, ri, isread); } -#ifndef CONFIG_USER_ONLY -static CPAccessResult pmreg_access_selr (CPUARMState *env,const ARMCPRegInfo *ri,bool isread)
@@ -1126,11 +1171,7 @@ static inline bool pmu_counter_filtered(CPUARMState *env, uint64_t pmxevtyper)*/ uint64_t pmccntr_op_start (CPUARMState *env) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env);if (arm_ccnt_enabled (env) && !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {
@@ -1268,26 +1309,6 @@ static void pmccntr_write32(CPUARMState *env, const ARMCPRegInfo *ri,pmccntr_write (env, ri,deposit64 (cur_val,0 ,32 , value)); } -#else /* CONFIG_USER_ONLY */ - -uint64_t pmccntr_op_start (CPUARMState *env) -{ -} - -void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) -{ -} - -uint64_t pmu_op_start (CPUARMState *env) -{ -} - -void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles) -{ -} - -#endif -static void pmccfiltr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {
@@ -1346,11 +1367,7 @@ static void pmevtyper_write(CPUARMState *env, const ARMCPRegInfo *ri,if (counter ==0x1f ) {pmccfiltr_write (env, ri, value); }else if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env);pmu_sync_counter (env, counter, cycles); env->cp15.c14_pmevtyper[counter] = value &0xfe0003ff ;pmu_sync_counter (env, counter, cycles);
@@ -1404,11 +1421,7 @@ static void pmevcntr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value, uint8_t counter) {if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env); env->cp15.c14_pmevcntr[counter] = value;pmu_sync_counter (env, counter, cycles); }
@@ -1420,12 +1433,8 @@ static uint64_t pmevcntr_read(CPUARMState *env, const ARMCPRegInfo *ri, uint8_t counter) {if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t ret; -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t ret, cycles; + cycles =get_cycle_count (env);pmu_sync_counter (env, counter, cycles); ret = env->cp15.c14_pmevcntr[counter];pmu_sync_counter (env, counter, cycles);
@@ -1613,7 +1622,6 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {/* Unimplemented so WI. */ { .name = "PMSWINC", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 4, .access = PL0_W, .accessfn = pmreg_access_swinc, .type = ARM_CP_NOP }, -#ifndef CONFIG_USER_ONLY { .name = "PMSELR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 5, .access = PL0_RW, .type = ARM_CP_ALIAS, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmselr),
@@ -1633,7 +1641,6 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .access = PL0_RW, .accessfn = pmreg_access_ccntr, .type = ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write, }, -#endif { .name = "PMCCFILTR", .cp = 15, .opc1 = 0, .crn = 14, .crm = 15, .opc2 = 7, .writefn = pmccfiltr_write_a32, .readfn = pmccfiltr_read_a32, .access = PL0_RW, .accessfn = pmreg_access,
@@ -5171,7 +5178,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)* field as main ID register, and we implement only the cycle * count register. */ -#ifndef CONFIG_USER_ONLY ARMCPRegInfo pmcr = { .name ="PMCR" , .cp =15 , .crn =9 , .crm =12 , .opc1 =0 , .opc2 =0 , .access =PL0_RW ,
@@ -5225,7 +5231,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)g_free (pmevtyper_name);g_free (pmevtyper_el0_name); } -#endif ARMCPRegInfo clidr = { .name ="CLIDR" , .state =ARM_CP_STATE_BOTH , .opc0 =3 , .crn =0 , .crm =0 , .opc1 =1 , .opc2 =1 ,
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [Qemu-devel] [Qemu-arm] [PATCH v3 20/22] target/arm: PMU: Add instruction and cycle events
Quoted 6 lines · Aaron Lindsay
The instruction event is only enabled when icount is used, cycles are always supported. Always defining
get_cycle_count(but altering its behavior depending onCONFIG_USER_ONLY) allows us to remove someCONFIG_USER_ONLY#defines throughout the rest of the code.Signed-off-by Aaron Lindsay <[email protected]>
Quoted 194 lines
--- target/arm/helper.c | 99 ++++++++++++++++++++++++++++------------------------- 1 file changed, 52 insertions(+), 47 deletions(-)target/arm/helper.c +52
-47@@ -15,6 +15,7 @@#include "arm_ldst.h" #include <zlib.h> /* For crc32 */ #include "exec/semihost.h" +#include "sysemu/cpus.h" #include "sysemu/kvm.h" #include "fpu/softfloat.h" @@ -935,8 +936,54 @@ typedef struct pm_event {uint64_t (*get_count)(CPUARMState *,uint64_t cycles); } pm_event; +/* +* Return the underlying cycle count for the PMU cycle counters. If we're in +* usermode, simply return 0. +*/ +static uint64_t get_cycle_count (CPUARMState *env) +{ +#ifndef CONFIG_USER_ONLY +return muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), +ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); +#else +return 0 ; +#endif +} + +static bool event_always_supported (CPUARMState *env) +{ +return true; +} + +#ifndef CONFIG_USER_ONLY +static uint64_t cycles_get_count (CPUARMState *env,uint64_t cycles) +{ +return cycles; +} + +static bool instructions_supported (CPUARMState *env) +{ +return use_icount ==1 /* Precise instruction counting */ ; +} + +static uint64_t instructions_get_count (CPUARMState *env,uint64_t cycles) +{ +return (uint64_t )cpu_get_icount_raw (); +} +#endif +#define SUPPORTED_EVENT_SENTINEL UINT16_MAXstatic const pm_event pm_events[] = { +#ifndef CONFIG_USER_ONLY + { .number =0x008 ,/* INST_RETIRED */ + .supported = instructions_supported, + .get_count = instructions_get_count + }, + { .number =0x011 ,/* CPU_CYCLES */ + .supported = event_always_supported, + .get_count = cycles_get_count + }, +#endif { .number =SUPPORTED_EVENT_SENTINEL } };static uint16_t supported_event_map[0x3f ];@@ -1016,8 +1063,6 @@ static CPAccessResult pmreg_access_swinc(CPUARMState *env,return pmreg_access (env, ri, isread); } -#ifndef CONFIG_USER_ONLY -static CPAccessResult pmreg_access_selr (CPUARMState *env,const ARMCPRegInfo *ri,bool isread)@@ -1126,11 +1171,7 @@ static inline bool pmu_counter_filtered(CPUARMState *env, uint64_t pmxevtyper)*/ uint64_t pmccntr_op_start (CPUARMState *env) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env);if (arm_ccnt_enabled (env) && !pmu_counter_filtered (env, env->cp15.pmccfiltr_el0)) {@@ -1268,26 +1309,6 @@ static void pmccntr_write32(CPUARMState *env, const ARMCPRegInfo *ri,pmccntr_write (env, ri,deposit64 (cur_val,0 ,32 , value)); } -#else /* CONFIG_USER_ONLY */ - -uint64_t pmccntr_op_start (CPUARMState *env) -{ -} - -void pmccntr_op_finish (CPUARMState *env,uint64_t prev_cycles) -{ -} - -uint64_t pmu_op_start (CPUARMState *env) -{ -} - -void pmu_op_finish (CPUARMState *env,uint64_t prev_cycles) -{ -} - -#endif -static void pmccfiltr_write (CPUARMState *env,const ARMCPRegInfo *ri,uint64_t value) {@@ -1346,11 +1367,7 @@ static void pmevtyper_write(CPUARMState *env, const ARMCPRegInfo *ri,if (counter ==0x1f ) {pmccfiltr_write (env, ri, value); }else if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env);pmu_sync_counter (env, counter, cycles); env->cp15.c14_pmevtyper[counter] = value &0xfe0003ff ;pmu_sync_counter (env, counter, cycles);@@ -1404,11 +1421,7 @@ static void pmevcntr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value, uint8_t counter) {if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t cycles =get_cycle_count (env); env->cp15.c14_pmevcntr[counter] = value;pmu_sync_counter (env, counter, cycles); }@@ -1420,12 +1433,8 @@ static uint64_t pmevcntr_read(CPUARMState *env, const ARMCPRegInfo *ri, uint8_t counter) {if (counter <PMU_NUM_COUNTERS (env)) { -uint64_t ret; -uint64_t cycles =0 ; -#ifndef CONFIG_USER_ONLY - cycles =muldiv64 (qemu_clock_get_ns (QEMU_CLOCK_VIRTUAL ), -ARM_CPU_FREQ ,NANOSECONDS_PER_SECOND ); -#endif +uint64_t ret, cycles; + cycles =get_cycle_count (env);pmu_sync_counter (env, counter, cycles); ret = env->cp15.c14_pmevcntr[counter];pmu_sync_counter (env, counter, cycles);@@ -1613,7 +1622,6 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {/* Unimplemented so WI. */ { .name = "PMSWINC", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 4, .access = PL0_W, .accessfn = pmreg_access_swinc, .type = ARM_CP_NOP }, -#ifndef CONFIG_USER_ONLY { .name = "PMSELR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 5, .access = PL0_RW, .type = ARM_CP_ALIAS, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmselr),@@ -1633,7 +1641,6 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .access = PL0_RW, .accessfn = pmreg_access_ccntr, .type = ARM_CP_IO, .readfn = pmccntr_read, .writefn = pmccntr_write, }, -#endif { .name = "PMCCFILTR", .cp = 15, .opc1 = 0, .crn = 14, .crm = 15, .opc2 = 7, .writefn = pmccfiltr_write_a32, .readfn = pmccfiltr_read_a32, .access = PL0_RW, .accessfn = pmreg_access,@@ -5171,7 +5178,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)* field as main ID register, and we implement only the cycle * count register. */ -#ifndef CONFIG_USER_ONLY ARMCPRegInfo pmcr = { .name ="PMCR" , .cp =15 , .crn =9 , .crm =12 , .opc1 =0 , .opc2 =0 , .access =PL0_RW ,@@ -5225,7 +5231,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)g_free (pmevtyper_name);g_free (pmevtyper_el0_name); } -#endif ARMCPRegInfo clidr = { .name ="CLIDR" , .state =ARM_CP_STATE_BOTH , .opc0 =3 , .crn =0 , .crm =0 , .opc1 =1 , .opc2 =1 ,
Re: [Qemu-arm] [PATCH v3 20/22] target/arm: PMU: Add instruction and cycle events
In reply to Aaron LindsayQuoted 7 lines · Aaron Lindsay
The instruction event is only enabled when icount is used, cycles are always supported. Always defining
get_cycle_count(but altering its behavior depending onCONFIG_USER_ONLY) allows us to remove someCONFIG_USER_ONLY#defines throughout the rest of the code.Signed-off-by Aaron Lindsay <[email protected]>---
[...]> #define SUPPORTED_EVENT_SENTINEL UINT16_MAX
Review
Quoted 3 lines
static const
pm_eventpm_events[] = {(quoted diff) +2
-0+#ifndef CONFIG_USER_ONLY + { .number = 0x008, /* INST_RETIRED */
"Instruction architecturally executed" seems more explicit to me.
Quoted 8 lines
target/arm/helper.c +8
-0+ .supported = instructions_supported, + .get_count = instructions_get_count + }, + { .number = 0x011, /* CPU_CYCLES */ + .supported = event_always_supported, + .get_count = cycles_get_count + }, +#endif
[...]
Re: [Qemu-arm] [PATCH v3 20/22] target/arm: PMU: Add instruction and cycle events
Quoted 6 lines · Philippe Mathieu-Daudé
Quoted 5 lines · Aaron Lindsay
The instruction event is only enabled when icount is used, cycles are always supported. Always defining
get_cycle_count(but altering its behavior depending onCONFIG_USER_ONLY) allows us to remove someCONFIG_USER_ONLY#defines throughout the rest of the code.
Quoted 8 lines
Quoted 2 lines
Signed-off-by Aaron Lindsay <[email protected]>---
[...]> #define
SUPPORTED_EVENT_SENTINELUINT16_MAXReview
Quoted 3 lines
static const
pm_eventpm_events[] = {(quoted diff) +2
-0+#ifndef CONFIG_USER_ONLY + { .number = 0x008, /* INST_RETIRED */"Instruction architecturally executed" seems more explicit to me.
I've updated v4 to include this wording as well.
Quoted 9 lines
Quoted 8 lines
target/arm/helper.c +8
-0+ .supported = instructions_supported, + .get_count = instructions_get_count + }, + { .number = 0x011, /* CPU_CYCLES */ + .supported = event_always_supported, + .get_count = cycles_get_count + }, +#endif [...]
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 21/22 target/arm: PMU: Set PMCR.N to 4
In reply to Aaron LindsayThis both advertises that we support four counters and adds them to the implementation because the PMU_NUM_COUNTERS macro reads this value from the PMCR.
--- target/arm/helper.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
target/arm/helper.c +3 -2
@@ -1575,7 +1575,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .access = PL1_W, .type = ARM_CP_NOP },/* Performance monitors are implementation defined in v7, * but with an ARM recommended set of registers, which we -* follow (although we don't actually implement any counters) +* follow. * * Performance registers fall into three categories: * (a) always UNDEF in PL0, RW in PL1 (PMINTENSET, PMINTENCLR)
@@ -5192,7 +5192,8 @@ void register_cp_regs_for_features(ARMCPU *cpu) .access = PL0_RW, .accessfn = pmreg_access, .type = ARM_CP_IO, .fieldoffset = offsetof(CPUARMState, cp15.c9_pmcr), - .resetvalue = cpu->midr & 0xff000000, + /* 4 counters enabled */ + .resetvalue = (cpu->midr & 0xff000000) | (0x4 << PMCRN_SHIFT), .writefn = pmcr_write, .raw_writefn = raw_write, };define_one_arm_cp_reg (cpu, &pmcr);
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 22/22 target/arm: Implement PMSWINC
In reply to Aaron Lindsay--- target/arm/helper.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-)
target/arm/helper.c +42 -2
@@ -955,6 +955,15 @@ static bool event_always_supported(CPUARMState *env)return true; } +static uint64_t swinc_get_count (CPUARMState *env,uint64_t cycles) +{ +/* +* SW_INCR events are written directly to the pmevcntr's by writes to +* PMSWINC, so there is no underlying count maintained by the PMU itself +*/ +return 0 ; +} +#ifndef CONFIG_USER_ONLY static uint64_t cycles_get_count (CPUARMState *env,uint64_t cycles) {
@@ -974,6 +983,10 @@ static uint64_t instructions_get_count(CPUARMState *env, uint64_t cycles)#define SUPPORTED_EVENT_SENTINEL UINT16_MAXstatic const pm_event pm_events[] = { + { .number =0x000 ,/* SW_INCR */ + .supported = event_always_supported, + .get_count = swinc_get_count + }, #ifndef CONFIG_USER_ONLY { .number =0x008 ,/* INST_RETIRED */ .supported = instructions_supported,
@@ -1273,6 +1286,29 @@ static void pmcr_write(CPUARMState *env, const ARMCPRegInfo *ri,pmu_op_finish (env, saved_cycles); } +static void pmswinc_write (CPUARMState *env,const ARMCPRegInfo *ri, +uint64_t value) +{ +unsigned int i; +for (i =0 ; i <PMU_NUM_COUNTERS (env); i++) { +/* Increment a counter's count iff: */ +if ((value & (1 << i)) &&/* counter's bit is set */ +/* counter is enabled and not filtered */ +pmu_counter_enabled (env, i) && + !pmu_counter_filtered (env, env->cp15.c14_pmevtyper[i]) && +/* counter is SW_INCR */ + (env->cp15.c14_pmevtyper[i] &PMXEVTYPER_EVTCOUNT ) ==0x0 ) { +uint64_t cycles =0 ; +#ifndef CONFIG_USER_ONLY + cycles =get_cycle_count (env); +#endif +pmu_sync_counter (env, i, cycles); + env->cp15.c14_pmevcntr[i]++; +pmu_sync_counter (env, i, cycles); + } + } +} +static uint64_t pmccntr_read (CPUARMState *env,const ARMCPRegInfo *ri) {uint64_t ret;
@@ -1619,9 +1655,13 @@ static const ARMCPRegInfo v7_cp_reginfo[] = { .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr), .writefn = pmovsr_write, .raw_writefn = raw_write }, -/* Unimplemented so WI. */ { .name = "PMSWINC", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 4, - .access = PL0_W, .accessfn = pmreg_access_swinc, .type = ARM_CP_NOP }, + .access = PL0_W, .accessfn = pmreg_access_swinc, .type = ARM_CP_NO_RAW, + .writefn = pmswinc_write }, + { .name = "PMSWINC_EL0", .state = ARM_CP_STATE_AA64, + .opc0 = 3, .opc1 = 3, .crn = 9, .crm = 12, .opc2 = 4, + .access = PL0_W, .accessfn = pmreg_access_swinc, .type = ARM_CP_NO_RAW, + .writefn = pmswinc_write }, { .name = "PMSELR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 5, .access = PL0_RW, .type = ARM_CP_ALIAS, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmselr),
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
This series seems to have some coding style problems. See output below for more information:
Hi,
This series seems to have some coding style problems. See output below for more information:
Type: series
Message-id: [email protected]
Subject: [Qemu-devel] [PATCH v3 00/22] More fully implement ARM PMUv3
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/[email protected] -> patchew/[email protected]
Switched to a new branch 'test'd81791b184 target/arm: Implement PMSWINC512124d018 target/arm: PMU: Set PMCR.N to 4b748e97306 target/arm: PMU: Add instruction and cycle events 7e46a77f89 target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER 82cffef855 target/arm: Add array for supported PMU events, generate PMCEID[01] d635021d0a target/arm: Split arm_ccnt_enabled into generic pmu_counter_enabled 3e1b438deb target/arm: Implement PMOVSSETc13c832988 target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions 9c80af4d82 target/arm: Make PMOVSCLR 64 bits wide8ffbcd3dd8 target/arm: Allow AArch32 access for PMCCFILTR 7dc4ec9715 target/arm: Filter cycle counter based on PMCCFILTR_EL0 f1e40f9fff target/arm: Fix bitmask for PMCCFILTR writes eb142b42b4 target/arm: Allow EL change hooks to do IOd37186abdd target/arm: Add pre-EL change hooksae12e161da target/arm: Support multiple EL change hooks 9bfa99805d target/arm: Fetch GICv3 state directly from CPUARMState 881bee5e96 target/arm: Mask PMU register writes based on PMCR_EL0.N 890ad6472b target/arm: Reorganize PMCCNTR read, write, sync 922eec023b target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0 5b1ce33c0b target/arm: Check PMCNTEN for whether PMCCNTR is enabled 2ecb09ae04 target/arm: A15 PMCEID0 initialization style nit 0f26a1568a target/arm: A53: Initialize PMCEID[01]
=== OUTPUT BEGIN ===
Checking PATCH 1/22: target/arm: A53: Initialize PMCEID[01]... Checking PATCH 2/22: target/arm: A15 PMCEID0 initialization style nit... Checking PATCH 3/22: target/arm: Check PMCNTEN for whether PMCCNTR is enabled... Checking PATCH 4/22: target/arm: Treat PMCCNTR as alias of PMCCNTR_EL0... Checking PATCH 5/22: target/arm: Reorganize PMCCNTR read, write, sync... Checking PATCH 6/22: target/arm: Mask PMU register writes based on PMCR_EL0.N... Checking PATCH 7/22: target/arm: Fetch GICv3 state directly from CPUARMState... Checking PATCH 8/22: target/arm: Support multiple EL change hooks...
ERROR: space prohibited between function name and open parenthesis '(' #26: FILE: target/arm/cpu.c:62:
+ entry = g_malloc0(sizeof (*entry));
total: 1 errors, 0 warnings, 87 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.
Checking PATCH 9/22: target/arm: Add pre-EL change hooks...
ERROR: space prohibited between function name and open parenthesis '(' #26: FILE: target/arm/cpu.c:62:
+ entry = g_malloc0(sizeof (*entry));
total: 1 errors, 0 warnings, 110 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.
Checking PATCH 10/22: target/arm: Allow EL change hooks to do IO... Checking PATCH 11/22: target/arm: Fix bitmask for PMCCFILTR writes... Checking PATCH 12/22: target/arm: Filter cycle counter based on PMCCFILTR_EL0... Checking PATCH 13/22: target/arm: Allow AArch32 access for PMCCFILTR... Checking PATCH 14/22: target/arm: Make PMOVSCLR 64 bits wide...
Checking PATCH 15/22: target/arm: Add ARM_FEATURE_V7VE for v7 Virtualization Extensions... Checking PATCH 16/22: target/arm: Implement PMOVSSET...
WARNING: line over 80 characters
#39: FILE: target/arm/helper.c:1417:
+ .access = PL0_RW, .fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr),
total: 0 errors, 1 warnings, 59 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 17/22: target/arm: Split arm_ccnt_enabled into generic pmu_counter_enabled... Checking PATCH 18/22: target/arm: Add array for supported PMU events, generate PMCEID[01]... Checking PATCH 19/22: target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER... Checking PATCH 20/22: target/arm: PMU: Add instruction and cycle events... Checking PATCH 21/22: target/arm: PMU: Set PMCR.N to 4...
Checking PATCH 22/22: target/arm: Implement PMSWINC...
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to [email protected]
My apologies for the below style issues - I've already fixed them up for v4...
-Aaron
Quoted 121 lines · On Mar 16 13:58, [email protected] wrote:
Hi,
This series seems to have some coding style problems. See output below for more information:
Type: series
Message-id: [email protected]
Subject: [Qemu-devel] [PATCH v3 00/22] More fully implement ARM PMUv3=== TEST SCRIPT BEGIN ===
#!/bin/bashBASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogramcommits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..." if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then failed=1 echo fi n=$((n+1))done
exit $failed
=== TEST SCRIPT END ===Updating
3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/[email protected] -> patchew/[email protected]
Switched to a new branch 'test'd81791b184target/arm: Implement PMSWINC512124d018target/arm: PMU: Set PMCR.N to 4b748e97306target/arm: PMU: Add instruction and cycle events7e46a77f89target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER82cffef855target/arm: Add array for supported PMU events, generate PMCEID[01]d635021d0atarget/arm: Splitarm_ccnt_enabledinto genericpmu_counter_enabled3e1b438debtarget/arm: Implement PMOVSSETc13c832988target/arm: AddARM_FEATURE_V7VEfor v7 Virtualization Extensions9c80af4d82target/arm: Make PMOVSCLR 64 bits wide8ffbcd3dd8target/arm: Allow AArch32 access for PMCCFILTR7dc4ec9715target/arm: Filter cycle counter based onPMCCFILTR_EL0f1e40f9ffftarget/arm: Fix bitmask for PMCCFILTR writeseb142b42b4target/arm: Allow EL change hooks to do IOd37186abddtarget/arm: Add pre-EL change hooksae12e161datarget/arm: Support multiple EL change hooks9bfa99805dtarget/arm: Fetch GICv3 state directly from CPUARMState881bee5e96target/arm: Mask PMU register writes based on PMCR_EL0.N890ad6472btarget/arm: Reorganize PMCCNTR read, write, sync922eec023btarget/arm: Treat PMCCNTR as alias ofPMCCNTR_EL05b1ce33c0btarget/arm: Check PMCNTEN for whether PMCCNTR is enabled2ecb09ae04target/arm: A15 PMCEID0 initialization style nit0f26a1568atarget/arm: A53: Initialize PMCEID[01]=== OUTPUT BEGIN ===
Checking PATCH 1/22: target/arm: A53: Initialize PMCEID[01]... Checking PATCH 2/22: target/arm: A15 PMCEID0 initialization style nit... Checking PATCH 3/22: target/arm: Check PMCNTEN for whether PMCCNTR is enabled... Checking PATCH 4/22: target/arm: Treat PMCCNTR as alias ofPMCCNTR_EL0... Checking PATCH 5/22: target/arm: Reorganize PMCCNTR read, write, sync... Checking PATCH 6/22: target/arm: Mask PMU register writes based on PMCR_EL0.N... Checking PATCH 7/22: target/arm: Fetch GICv3 state directly from CPUARMState... Checking PATCH 8/22: target/arm: Support multiple EL change hooks...
ERROR: space prohibited between function name and open parenthesis '(' #26: FILE:target/arm/cpu.c:62:
+ entry =g_malloc0(sizeof (*entry));total: 1 errors, 0 warnings, 87 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in
MAINTAINERS.Checking PATCH 9/22: target/arm: Add pre-EL change hooks...
ERROR: space prohibited between function name and open parenthesis '(' #26: FILE:target/arm/cpu.c:62:
+ entry =g_malloc0(sizeof (*entry));total: 1 errors, 0 warnings, 110 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in
MAINTAINERS.Checking PATCH 10/22: target/arm: Allow EL change hooks to do IO... Checking PATCH 11/22: target/arm: Fix bitmask for PMCCFILTR writes... Checking PATCH 12/22: target/arm: Filter cycle counter based on
PMCCFILTR_EL0... Checking PATCH 13/22: target/arm: Allow AArch32 access for PMCCFILTR... Checking PATCH 14/22: target/arm: Make PMOVSCLR 64 bits wide...
Checking PATCH 15/22: target/arm: AddARM_FEATURE_V7VEfor v7 Virtualization Extensions... Checking PATCH 16/22: target/arm: Implement PMOVSSET...
WARNING: line over 80 characters
#39: FILE:target/arm/helper.c:1417:
+ .access =PL0_RW, .fieldoffset =offsetoflow32(CPUARMState, cp15.c9_pmovsr),total: 0 errors, 1 warnings, 59 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH inMAINTAINERS.
Checking PATCH 17/22: target/arm: Splitarm_ccnt_enabledinto genericpmu_counter_enabled... Checking PATCH 18/22: target/arm: Add array for supported PMU events, generate PMCEID[01]... Checking PATCH 19/22: target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER... Checking PATCH 20/22: target/arm: PMU: Add instruction and cycle events... Checking PATCH 21/22: target/arm: PMU: Set PMCR.N to 4...
Checking PATCH 22/22: target/arm: Implement PMSWINC...
=== OUTPUT END ===Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to [email protected]
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v3 1/1 RFC: target/arm: Send interrupts on PMU counter overflow
In reply to Aaron LindsayQuoted 8 lines · Aaron Lindsay
I aim to eventually add raising interrupts on counter overflow, but that is not covered by this patchset. I think I have a reasonable grasp of the mechanics of *how* to raise them, but am curious if anyone has thoughts on how to determine *when* to raise them - we don't want to call into PMU code every time an instruction is executed to check if any instruction counters have overflowed, etc. The main candidate I've seen for doing this so far would be to set up a QEMUTimer, but I haven't fully explored it. Does that seem plausible? Any other/better ideas?
I'm planning to post a full v4 of this patchset soon, pending a few review fixes, but I figured I'd throw out an early version of a patch to add interrupts on overflow in case it obviously has major issues that will need to be addressed.
This patch sets up a QEMUTimer to get a callback when we expect counters to next overflow and triggers an interrupt at that time.
--- target/arm/cpu.c | 11 +++++ target/arm/cpu.h | 7 +++ target/arm/helper.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 138 insertions(+), 9 deletions(-)
target/arm/cpu.c +11 -0
@@ -740,6 +740,12 @@ static void arm_cpu_finalizefn(Object *obj)QLIST_REMOVE (hook, node);g_free (hook); } +#ifndef CONFIG_USER_ONLY +if (arm_feature (&cpu->env,ARM_FEATURE_PMU )) { +timer_deinit (cpu->pmu_timer); +timer_free (cpu->pmu_timer); + } +#endif }static void arm_cpu_realizefn (DeviceState *dev,Error **errp)
@@ -907,6 +913,11 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)arm_register_pre_el_change_hook (cpu, &pmu_pre_el_change,0 );arm_register_el_change_hook (cpu, &pmu_post_el_change,0 ); + +#ifndef CONFIG_USER_ONLY + cpu->pmu_timer =timer_new (QEMU_CLOCK_VIRTUAL ,1 , arm_pmu_timer_cb, + cpu); +#endif }else { cpu->pmceid0 =0x00000000 ; cpu->pmceid1 =0x00000000 ;
target/arm/cpu.h +7 -0
@@ -703,6 +703,8 @@ struct ARMCPU {/* Timers used by the generic (architected) timer */ QEMUTimer *gt_timer[NUM_GTIMERS ]; +/* Timer used by the PMU */ +QEMUTimer *pmu_timer;/* GPIO outputs for generic timer */ qemu_irq gt_timer_outputs[NUM_GTIMERS ];/* GPIO output for GICv3 maintenance interrupt signal */
@@ -934,6 +936,11 @@ void pmu_op_start(CPUARMState *env);void pmu_op_finish (CPUARMState *env);/** +* Called when a PMU counter is due to overflow +*/ +void arm_pmu_timer_cb (void *opaque); + +/** * Functions to register as EL change hooks for PMU mode filtering */ void pmu_pre_el_change (ARMCPU *cpu,void *ignored);
target/arm/helper.c +120 -9
261 lines not on this page · raw message
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Quoted 6 lines · Aaron Lindsay
The ARM PMU implementation currently contains a basic cycle counter, but it is often useful to gather counts of other events and filter them based on execution mode. These patches flesh out the implementations of various PMU registers including PM[X]EVCNTR and PM[X]EVTYPER, add a struct definition to represent arbitrary counter types, implement mode filtering, and add instruction, cycle, and software increment events.
Hi; sorry it's taken me a while to get to this (I've been focusing on for-2.12 work). I've now reviewed most of the patches in this set. My suggestion is that you fix the stuff I've commented on and send out a v4, and then I can take some of the patches from the start of that into target-arm.next, and I'll review the tail end of the set then.
thanks
-- PMM
Quoted 8 lines · Peter Maydell
Quoted 6 lines · Aaron Lindsay
The ARM PMU implementation currently contains a basic cycle counter, but it is often useful to gather counts of other events and filter them based on execution mode. These patches flesh out the implementations of various PMU registers including PM[X]EVCNTR and PM[X]EVTYPER, add a struct definition to represent arbitrary counter types, implement mode filtering, and add instruction, cycle, and software increment events.
Quoted 6 lines
Hi; sorry it's taken me a while to get to this (I've been focusing on for-2.12 work). I've now reviewed most of the patches in this set. My suggestion is that you fix the stuff I've commented on and send out a v4, and then I can take some of the patches from the start of that into target-arm.next, and I'll review the tail end of the set then.
Thanks for the review! I'll see if I can get a v4 out late this week or early next.
I'll make a note of this when I send it out, but one thing to look out for in the next version is that I had to reorganize a few things to make the interrupt-on-overflow functionality work better. I think the changes are fairly minor and limited to the later patches, with the possible exception of using two variables per counter (because you have to know what the previous counter value was in addition to the current value to know if you've overflowed since your last check).
-Aaron
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.