Re: [Qemu-devel] ARM QOM conversion / class hierarchy

[Paul Brook <paul@codesourcery.com>]

> >> 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.