Re: [Qemu-devel] [PATCH] target-arm: support for ARM1176JZ-s cores

[Jamie Iles]

On Wed, Jun 22, 2011 at 10:40:12AM +0100, Peter Maydell wrote:
> On 22 June 2011 00:42, Jamie Iles <address@hidden> wrote:
> > On 21 June 2011 23:13, Peter Maydell <address@hidden> wrote:
> >> Ah yes, sorry, I misread the TRM there. So it does have those, it's
> >> just the SEV/WFI/WFE it is missing. I guess we'll want an
> >> ARM_FEATURE_VAPA too.
> >
> > Could we perhaps infer and detect some of these features?  For example,
> > my reading of the ARM ARM says that the VA<->PA translation registers
> > exist for >v7 or v6k if the security extensions exist.  We can detect
> > the security extensions from the cpuid registers so we could
> > automatically set that feature.
> 
> I thought about that, but there are a couple of reasons I'd rather
> not detect things from the cpuid/feature registers:
>  * older cores don't have them, so you need to cope without them anyway
>  * there's a tension between "emulate the same feature regs as the
>    h/w" and "emulate feature regs matching what we implement" -- some
>    guest OSes will actually refuse to boot unless they get exact matches
>    on the feature reg values...
>    (At the moment we tend to the former, so we probably advertise the
>    security extensions even though we don't implement them, for instance)
>  * at the moment the feature regs are just random hex values in helper.c;
>    if we wanted to drive things from them we'd need to set up a lot of
>    enumerations and constants anyway in order to have something maintainable
> 
> Inferring ARM_FEATURE_foo flags from other ARM_FEATURE_foo flags is fine,
> though.
> 
> Mostly what I'd like is for the actual code implementing things to
> be gated on a fairly fine-grained set of flags, so that we can confine
> the "what does this core have? what things imply what other things?"
> code to a single place where it's easy to tweak if we get it wrong.

OK, I don't think I can object to that!  I'll submit a patch to fix up 
the v7 VMSA ap/remap dependency to be v6K rather than v7.  Given that, 
do you have any objection to adding 1167 as a v6K?  I'm happy to help 
with/test some of the feature cleanup.

Jamie