On Sat, 9 Apr 2022 at 01:14, Richard Henderson
<[email protected]> wrote:
>
> Share the code to set AArch32 max features so that we no
> longer have code drift between qemu{-system,}-{arm,aarch64}.
>
> Signed-off-by: Richard Henderson <[email protected]>
> ---
> target/arm/internals.h | 2 +
> target/arm/cpu64.c | 51 +----------------
> target/arm/cpu_tcg.c | 121 ++++++++++++++++++++++-------------------
> 3 files changed, 70 insertions(+), 104 deletions(-)
> +/* Share AArch32 -cpu max features with AArch64. */
> +void arm32_max_features(ARMCPU *cpu)
> +{
> + uint32_t t;
> +
> + /* Break with true ARMv8 and add back old-style VFP short-vector support
> */
> + t = cpu->isar.mvfr0;
> + t = FIELD_DP32(t, MVFR0, FPSHVEC, 1);
> + cpu->isar.mvfr0 = t;
So, we definitely want to enable short-vector support for
qemu-arm -cpu max, but I'm less convinced that we want to
enable it for qemu-system-arm -cpu max, and definitely don't
think we want to enable it for system-mode qemu-system-aarch64.
'max' for usermode has more of a flavour of "run as many binaries
as we can", especially since it's the default; 'max' for system
emulation mode is more "latest and greatest", which might imply
"some very old stuff is no longer available".
thanks
-- PMM