Peter Maydell <peter.mayd...@linaro.org> writes:
> On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.ben...@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
