| Message ID | 20190722111914.28574-1-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC,for,4.2] target/arm: generate a custom MIDR for -cpu max | expand |
On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote: > > While most features are now detected by probing the ID_* registers > kernels can (and do) use MIDR_EL1 for working out of they have to > apply errata. This can trip up warnings in the kernel as it tries to > work out if it should apply workarounds to features that don't > actually exist in the reported CPU type. > > Avoid this problem by synthesising our own MIDR value using the > reserved value of 0 for the implementer and encoding the moving feast > that is the QEMU version string into the other fields. Exposing the QEMU_VERSION_* information to the guest is usually not a good plan. For instance it means that the MIDR will mysteriously change if you save a VM on one version of QEMU and restore it on another. We went through a while back carefully removing places where we'd exposed the version number to the guest (have a look at the qemu_hw_version() stuff which has to jump through hoops so that old versioned machines like pc-1.5 report the old "1.5" version number, and any QEMU 2.5 and above now reports "2.5+"...) thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote: >> >> While most features are now detected by probing the ID_* registers >> kernels can (and do) use MIDR_EL1 for working out of they have to >> apply errata. This can trip up warnings in the kernel as it tries to >> work out if it should apply workarounds to features that don't >> actually exist in the reported CPU type. >> >> Avoid this problem by synthesising our own MIDR value using the >> reserved value of 0 for the implementer and encoding the moving feast >> that is the QEMU version string into the other fields. > > Exposing the QEMU_VERSION_* information to the guest is > usually not a good plan. For instance it means that the > MIDR will mysteriously change if you save a VM on one > version of QEMU and restore it on another. Given the mutability of -cpu max that is probably a good thing? > We went through > a while back carefully removing places where we'd exposed > the version number to the guest (have a look at the > qemu_hw_version() stuff which has to jump through hoops > so that old versioned machines like pc-1.5 report the > old "1.5" version number, and any QEMU 2.5 and above > now reports "2.5+"...) Well I guess we could do: cpu->midr = FIELD_DP64(0, MIDR_EL1, ARCHITECTURE, 0xf) but any kernel that attempts to apply fixups for a 0x0 implementer is asking for trouble anyway. I assume it's unlikely ARM would assign QEMU an implementer code! > > thanks > -- PMM -- Alex Bennée
diff --git a/target/arm/cpu.h b/target/arm/cpu.h index 7efbb488d9d..61eaef924e4 100644 --- a/target/arm/cpu.h +++ b/target/arm/cpu.h @@ -1605,6 +1605,12 @@ FIELD(V7M_FPCCR, ASPEN, 31, 1) /* * System register ID fields. */ +FIELD(MIDR_EL1, REVISION, 0, 4) +FIELD(MIDR_EL1, PARTNUM, 4, 12) +FIELD(MIDR_EL1, ARCHITECTURE, 16, 4) +FIELD(MIDR_EL1, VARIENT, 20, 4) +FIELD(MIDR_EL1, IMPLEMENTER, 24, 8) + FIELD(ID_ISAR0, SWAP, 0, 4) FIELD(ID_ISAR0, BITCOUNT, 4, 4) FIELD(ID_ISAR0, BITFIELD, 8, 4) diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index b1bb394c6dd..c121d0b37e0 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -296,6 +296,16 @@ static void aarch64_max_initfn(Object *obj) uint32_t u; aarch64_a57_initfn(obj); + /* reset MIDR so our franken-max-cpu type isn't mistaken for a real one */ + t = 0; + t = FIELD_DP64(t, MIDR_EL1, IMPLEMENTER, 0); /* Reserved for SW */ + t = FIELD_DP64(t, MIDR_EL1, ARCHITECTURE, 0xf); /* See ID_* for details */ + /* Encode QEMU version details */ + t = FIELD_DP64(t, MIDR_EL1, VARIENT, QEMU_VERSION_MAJOR); + t = FIELD_DP64(t, MIDR_EL1, REVISION, QEMU_VERSION_MINOR); + t = FIELD_DP64(t, MIDR_EL1, PARTNUM, QEMU_VERSION_MICRO); + cpu->midr = t; + t = cpu->isar.id_aa64isar0; t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* AES + PMULL */ t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1);
While most features are now detected by probing the ID_* registers kernels can (and do) use MIDR_EL1 for working out of they have to apply errata. This can trip up warnings in the kernel as it tries to work out if it should apply workarounds to features that don't actually exist in the reported CPU type. Avoid this problem by synthesising our own MIDR value using the reserved value of 0 for the implementer and encoding the moving feast that is the QEMU version string into the other fields. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- target/arm/cpu.h | 6 ++++++ target/arm/cpu64.c | 10 ++++++++++ 2 files changed, 16 insertions(+) -- 2.20.1