Hi,
On 11/02/18 18:16, Peter Maydell wrote:
> From: Richard Henderson <richard.hender...@linaro.org>
>
> When populating id registers from kvm, on a host that doesn't support
> aarch32 mode at all, neither arm_div nor jazelle will be supported either.
>
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
> Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
> Tested-by: Alex Bennée <alex.ben...@linaro.org>
> Message-id: 20181102102025.3546-1-richard.hender...@linaro.org
> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> ---
> target/arm/cpu.h | 5 +++++
> target/arm/cpu.c | 15 +++++++++++++--
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 8e6779936eb..b5eff79f73b 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -3296,6 +3296,11 @@ static inline bool isar_feature_aa64_fp16(const
> ARMISARegisters *id)
> return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, FP) == 1;
> }
>
> +static inline bool isar_feature_aa64_aa32(const ARMISARegisters *id)
> +{
> + return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, EL0) >= 2;
> +}
> +
> static inline bool isar_feature_aa64_sve(const ARMISARegisters *id)
> {
> return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, SVE) != 0;
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 8f16e96b6c8..784a4c2dfcc 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -774,6 +774,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> CPUARMState *env = &cpu->env;
> int pagebits;
> Error *local_err = NULL;
> + bool no_aa32 = false;
>
> /* If we needed to query the host kernel for the CPU features
> * then it's possible that might have failed in the initfn, but
> @@ -820,6 +821,16 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> set_feature(env, ARM_FEATURE_V7VE);
> }
> }
> +
> + /*
> + * There exist AArch64 cpus without AArch32 support. When KVM
> + * queries ID_ISAR0_EL1 on such a host, the value is UNKNOWN.
> + * Similarly, we cannot check ID_AA64PFR0 without AArch64 support.
> + */
> + if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
> + no_aa32 = !cpu_isar_feature(aa64_aa32, cpu);
> + }
> +
> if (arm_feature(env, ARM_FEATURE_V7VE)) {
> /* v7 Virtualization Extensions. In real hardware this implies
> * EL2 and also the presence of the Security Extensions.
> @@ -829,7 +840,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
> * Security Extensions is ARM_FEATURE_EL3.
> */
> - assert(cpu_isar_feature(arm_div, cpu));
> + assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
The assertion above fails on my AArch64 host (APM Mustang A3). Meaning
that my host CPU supports AArch32, but lacks "arm_div".
(My understanding is that this commit, i.e., 0f8d06f16c9d, relaxed the
assert originally added in commit 7e0cf8b47f0e ("target/arm: Convert
division from feature bits to isar0 tests", 2018-10-24). Can we relax it
even further?
Better yet: can we rework the code to emit a warning, rather than
aborting QEMU? Assertions are not the best tool IMHO for catching
unusual (or slightly non-conformant / early) hardware.)
Thanks,
Laszlo
> set_feature(env, ARM_FEATURE_LPAE);
> set_feature(env, ARM_FEATURE_V7);
> }
> @@ -855,7 +866,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> if (arm_feature(env, ARM_FEATURE_V6)) {
> set_feature(env, ARM_FEATURE_V5);
> if (!arm_feature(env, ARM_FEATURE_M)) {
> - assert(cpu_isar_feature(jazelle, cpu));
> + assert(no_aa32 || cpu_isar_feature(jazelle, cpu));
> set_feature(env, ARM_FEATURE_AUXCR);
> }
> }
>
