On 6 October 2011 11:16, Andreas Färber <andreas.faer...@web.de> wrote: > Am 02.10.2011 23:44, schrieb Peter Maydell: >> On 2 October 2011 19:56, Andreas Färber <andreas.faer...@web.de> wrote: >>> 1) Currently, -cpu is used to look up a Main ID Register value and to base >>> feature decisions on that. This doesn't work for Cortex-R4 and Cortex-R4F, >>> which have an identical MIDR but only -R4F has the FPU. >>> Re-checking the model string, while ugly, does the trick. Comments? >> >> That is indeed kind of ugly. I think if CPUID value isn't a unique value >> for the things we pass to -cpu then we shouldn't treat it as one. > > For the reset, the MIDR is read, then the memset() is performed and > cpu_reset_model_id() is called with the previously read MIDR value, > which the function then writes into the register first thing. I'd > suggest to move that out into cpu_reset(), drop the id parameter and > switch on the register instead (only other use is cpu_abort()).
If we're shuffling code around we should probably be doing something like: * in cpu_arm_init() look at the model string and set feature switches, ID register values, etc * in reset, don't reset ID registers (they're constant, after all), and [as with the rest of the code] behave based only on cpuid and feature switches >> More >> generally, it would be nice to be able to say "I want a Cortex-A9 >> but I only want the no-neon VFPv3D16 variant". (I think some of the >> other targets already have syntax for this.) > > Coming from a ppc background, we have a whole matrix of processors with > fixed features but I'm not aware of an arch where we opt-in/out > processor core features. target-i386 seems to have some code for handling syntax like this (you seem to be able to say -cpu pentium,-fpu for instance). >> I think that (1) the bare CPU name should be the most recent rev of the >> core that QEMU knows about [and that we should be happy to change qemu >> to move up to supporting newer revisions] > >> (Anybody want to argue with (1) ?) > > I concur that an easy-to-type -cpu should provide the latest and > greatest features. Features hidden will not get much exposure. But if a > revision noticeably changes behavior, I guess we should remain command > line compatible. Depends what you mean by "noticeably". User space will basically never notice or care, typically. The kernel does care occasionally. I think I'd rather have "cortex-foo" do the right thing for the vast majority of users who don't care whether they get r2 or r3, rather than be stuck with it meaning r1 because that's what we happened to model first and there was some minor incompatible change between r1 and r2. I don't think there's a position between "cortex-foo is always the most recent rev we model" and "user must always specify rXpY" which doesn't lead you into weird and confusing UI inconsistencies between CPUs. -- PMM
