Re: [Qemu-devel] [RFC] target-arm: Preserve CPUID over CPU reset

[Peter Maydell]

On 22 October 2011 12:00, Andreas Färber <address@hidden> wrote:
> Previously the CPUID register was set in cpu_arm_init() based on -cpu
> model. The CPU was then reset, requiring to save the CPUID and restore
> it afterwards.
>
> Change the storage location of c0_cpuid so that it does not get cleared.

I think this is the wrong approach. c0_cpuid should not be handled
any differently from any of the other read-only cp15 registers...

> OMAP appears to be special in that the CPUID can be switched between
> TI915T and TI925T on write. Therefore preserve cpu_reset_model_id() in
> slightly simplified form, allowing OMAP to reset the CPUID to TI925.

...and indeed it's not even purely r/o on those cores.

I don't think we should be doing things based on c0_cpuid. At the
moment we use it for:
 * determining whether we should implement the MPIDR (v7 or 11mpcore)
    -- we should define and use a feature bit instead
 * identifying what to return as the ACTLR value
    -- we should handle this like the other implementation-specific
       cp15 registers instead
 * code in cpu_reset_model_id which sets feature bits and various
   default register values
    -- see below

For cp15 registers I think we need to move to something more like
how target-ppc handles SPRs -- a registration routine of some
kind so each implementation can provide the cp15 registers it
requires and we don't get tangled up in huge nested switch statements
or splitting of "is this register present/ro/whatever?" between
translate.c and helper.c. If we do that then obviously "reset value"
is one of the things you feed in when you register the register,
and we only do the registration once from cpu_init, not at reset.

So cpu_arm_init should pick a base model (defining mostly a set
of cp15 regs and feature bits) and the user can also tweak the
feature bits (cf target-i386 +/-foo syntax), and reset no longer
needs to care at all what "cpu model" the user specified.

-- PMM