Hi Peter,
On 03/28/2014 12:09 PM, Peter Maydell wrote:
> Suppress the ID_AA64DFR0_EL1 PMUVer field, even if the CPU specific
> value claims that it exists. QEMU doesn't currently implement it,
> and not advertising it prevents the guest from trying to use it
> and getting UNDEFs on unimplemented registers.
>
> Signed-off-by: Peter Maydell <peter.maydell@xxxxxxxxxx>
> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx>
> ---
> This is arguably a hack, but otherwise Linux tries to prod
> half a dozen PMU sysregs.
> ---
> target-arm/helper.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 4b6c1b6..62f7fd3 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -2036,7 +2036,12 @@ void register_cp_regs_for_features(ARMCPU *cpu)
> { .name = "ID_AA64DFR0_EL1", .state = ARM_CP_STATE_AA64,
> .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 5, .opc2 = 0,
> .access = PL1_R, .type = ARM_CP_CONST,
> - .resetvalue = cpu->id_aa64dfr0 },
> + /* We mask out the PMUVer field, beacuse we don't currently
> + * implement the PMU. Not advertising it prevents the guest
> + * from trying to use it and getting UNDEFs on registers we
> + * don't implement.
> + */
> + .resetvalue = cpu->id_aa64dfr0 & ~0xf00 },
> { .name = "ID_AA64DFR1_EL1", .state = ARM_CP_STATE_AA64,
> .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 5, .opc2 = 1,
> .access = PL1_R, .type = ARM_CP_CONST,
Is the A32 port able to communicate the instruction count to target software
via the PMU?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
