> >> Yes, I think I'd agree there. So should we just have an init function > >> that provides the implementation-specific cp15 registers based on the > >> value provided in the QOM property for the main ID register? > > > > Something like that, yes. I'm not convinced the main ID register is the > > right property to use, but for actual implementation specific bits > > (rather than bits where an implementation picks one of a few common > > options) I guess we don't have any alternative but enumerating the > > implementations we support. > > Mmm, the disgusting thing the TI925T has where it can programmatically > change the value of its main ID register does somewhat argue against using > it for this.
I was thinking more for when we have multiple revisions of a chip that are (for these purposes) the same. Currently we only have this for pxa, but in principle we probably want it for others. As I mentioned on IRC, this isn't particularly interesting for Linux, which will happily run on pretty much anything. However there are other systems that care[1] whether the core reports itself as e.g. arm1136-r0p1 v.s. arm1136-r0p2. Paul [1] The reason for this is usually not relevant to qemu. e.g. They've got a hardcoded table of known CPUID values, and arbitrarily refuse to run on anything else. Or you're checking that a workaround for a particular silicon errata doesn't make anything else explode.
