[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] ARM QOM conversion / class hierarchy
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] ARM QOM conversion / class hierarchy |
Date: |
Tue, 20 Mar 2012 17:14:44 +0000 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.7.4; x86_64; ; ) |
> >> 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.
Re: [Qemu-devel] ARM QOM conversion / class hierarchy, Anthony Liguori, 2012/03/20
Re: [Qemu-devel] ARM QOM conversion / class hierarchy, Michael Roth, 2012/03/20