On Thu, Aug 05, 2021 at 04:30:43PM +0900, Shuuichirou Ishii wrote:
> Add a definition for the Fujitsu A64FX processor.
>
> The A64FX processor does not implement the AArch32 Execution state,
> so there are no associated AArch32 Identification registers.
>
> Signed-off-by: Shuuichirou Ishii <ishii.shuuic...@fujitsu.com>
> ---
> target/arm/cpu64.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index c690318a9b..612644941b 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -847,10 +847,54 @@ static void aarch64_max_initfn(Object *obj)
> cpu_max_set_sve_max_vq, NULL, NULL);
> }
>
> +static void aarch64_a64fx_initfn(Object *obj)
> +{
> + ARMCPU *cpu = ARM_CPU(obj);
> +
> + cpu->dtb_compatible = "arm,a64fx";
> + set_feature(&cpu->env, ARM_FEATURE_V8);
> + set_feature(&cpu->env, ARM_FEATURE_NEON);
> + set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
> + set_feature(&cpu->env, ARM_FEATURE_AARCH64);
> + set_feature(&cpu->env, ARM_FEATURE_EL2);
> + set_feature(&cpu->env, ARM_FEATURE_EL3);
> + set_feature(&cpu->env, ARM_FEATURE_PMU);
> + cpu->midr = 0x461f0010;
> + cpu->revidr = 0x00000000;
> + cpu->ctr = 86668006;
> + cpu->reset_sctlr = 0x30000180;
> + cpu->isar.id_aa64pfr0 = 0x0000000101111111; /* No RAS Extensions */
> + cpu->isar.id_aa64pfr1 = 0x0000000000000000;
> + cpu->isar.id_aa64dfr0 = 0x0000000010305408;
> + cpu->isar.id_aa64dfr1 = 0x0000000000000000;
> + cpu->id_aa64afr0 = 0x0000000000000000;
> + cpu->id_aa64afr1 = 0x0000000000000000;
> + cpu->isar.id_aa64mmfr0 = 0x0000000000001122;
> + cpu->isar.id_aa64mmfr1 = 0x0000000011212100;
> + cpu->isar.id_aa64mmfr2 = 0x0000000000001011;
> + cpu->isar.id_aa64isar0 = 0x0000000010211120;
> + cpu->isar.id_aa64isar1 = 0x0000000000010001;
> + cpu->isar.id_aa64zfr0 = 0x0000000000000000;
> + cpu->clidr = 0x0000000080000023;
> + cpu->ccsidr[0] = 0x7007e01c; /* 64KB L1 dcache */
> + cpu->ccsidr[1] = 0x2007e01c; /* 64KB L1 icache */
> + cpu->ccsidr[2] = 0x70ffe07c; /* 8MB L2 cache */
> + cpu->dcz_blocksize = 6; /* 256 bytes */
> + cpu->gic_num_lrs = 4;
> + cpu->gic_vpribits = 5;
> + cpu->gic_vprebits = 5;
> + /* TODO: Add A64FX specific HPC extension registers */
> +
> + aarch64_add_sve_properties(obj);
> + object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_max_vq,
> + cpu_max_set_sve_max_vq, NULL, NULL);
I'm not a huge fan of the sve-max-vq property since it's not a good idea
to use it with KVM, because it's not explicit enough for migration[1]. I
realize the a64fx cpu type will likely never be used with KVM, but since
sve-max-vq isn't necessary[2], than I would avoid propagating it to
another cpu type. Finally, if you want the a64fx cpu model to represent
the current a64fx cpu, then don't you want to explicitly set the supported
vector lengths[3] and deny the user the option to change them? You could
do that by directly setting the vq map and not adding the sve properties.
[1] With KVM, sve-max-vq only tells you the maximum vq, but it won't tell
you that the host doesn't support non-power-of-2 vector lengths. So you
don't get an explicit vector length list on the command line. Being
explicit is the only safe way to migrate (see
docs/system/arm/cpu-features.rst:"SVE CPU Property Recommendations").
[2] If a shorthand is desired for specifying vector lengths, then just
use a single sve<N> property. For example, sve-max-vq=4 and sve512=on
are identical (but keep [1] in mind).
[3] a64fx only support 128, 256, and 512 bit vector lengths, afaik.
Thanks,
drew
> +}
> +
> static const ARMCPUInfo aarch64_cpus[] = {
> { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
> { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
> { .name = "cortex-a72", .initfn = aarch64_a72_initfn },
> + { .name = "a64fx", .initfn = aarch64_a64fx_initfn },
> { .name = "max", .initfn = aarch64_max_initfn },
> };
>
> --
> 2.27.0
>
>
