Provided that it is not inlined (which it shouldn't be since it is in the .c file), this seems like the kind of function that could be skipped (as wedo for udelay) and handled by the simulator.

[The diff doesn't apply, but I was able to see the kernel change in the reject file. ]

True, however if you use a system that supports an A15 you don't need either change, although you do need a one line change to the boot loader that I'm going to commit any day now. The problem that then crops up is how to relate gem5's flat and linear cpu numbering scheme to the clustered scheme that is described in the A15 MPIDR register. Unfortunately, this comes back to needing some type of container classes (Core vs CPU) (CPU vs Cluster) ... as well as some sensible way to apply allow cores to get architecture specific configuration structures that describe things like cluster affinity level or CPUID if you want to model a heterogeneous system and let the kernel know that the cores are heterogeneous so it can make more intelligent scheduling decisions. 

Lastly, there has been so much churn in the linux kernel around ARM support lately to deal with the switch to device trees that it seems painful to try and deal with that at the moment.