On 2022/5/7 2:02, Richard Henderson wrote:
+static void aarch64_neoverse_n1_initfn(Object *obj)
+{
+ ARMCPU *cpu = ARM_CPU(obj);
+
+ cpu->dtb_compatible = "arm,neoverse-n1";
+ 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_CBAR_RO);
+ set_feature(&cpu->env, ARM_FEATURE_EL2);
+ set_feature(&cpu->env, ARM_FEATURE_EL3);
+ set_feature(&cpu->env, ARM_FEATURE_PMU);
+
+ /* Ordered by B2.4 AArch64 registers by functional group */
+ cpu->clidr = 0x82000023;
+ cpu->ctr = 0x8444c004;
+ cpu->dcz_blocksize = 4;
+ cpu->isar.id_aa64dfr0 = 0x0000000110305408ull;
The r4p1 TRM says that the Neoverse N1 core supports SPE (the value
of ID_AA64DFR0.PMSVer is 0b0001) but do we really support SPE
emulation in QEMU?
The guest immediately received an unexpected exception (with EC==0,
at EFI stage) when I tried to boot it using something like:
/path/to/qemu-system-aarch64 \
-M virt,gic-version=3,virtualization=on \
-cpu neoverse-n1 -accel tcg \
-bios QEMU_EFI.fd [...]
and QEMU shouted that "read access to unsupported AArch64 system
register op0:3 op1:0 crn:9 crm:10 op2:7", which told us that the
guest attempted to read the PMBIDR_EL1 register.
Zenghui
