[PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Tue, Jan 04, 2011 at 11:00:05AM -0800, David Brown wrote:
> On Tue, Jan 04 2011, Nicolas Pitre wrote:
> 
> > On Tue, 4 Jan 2011, David Brown wrote:
> >
> >> Any idea how much it would hurt other targets to have the
> >> __virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
> >> the upper 8 bits are used?
> >
> > Probably not that much.  But let's make it work satisfactorily for the 
> > general case first, and then we might consider and test variations that 
> > could accommodate msm.
> 
> Sounds like a good plan.  We've got quite a few other things to clean up
> before we can build for more than one arch anyway.

Actually, we can do this quite easily.  Having a config symbol which
gets enabled when MSM is added, which then enables two consecutive
__pv_fixups gives us 16-bits to play with.

As I originally intended with my implementation, the value field of the
instruction can be used to identify what this fixup is about - and we
can put that to use by selecting either bits 31-24 or 23-16 of the
offset value.

This still allows optimizations to happen with instruction scheduling -
eg, for the MSM kernel I've just built with this enabled:

c000b320:       e2844001        add     r4, r4, #1      ; 0x1
c000b324:       e59f3264        ldr     r3, [pc, #612]  ; c000b590 <setup_arch+0x690>
c000b328:       e2844000        add     r4, r4, #0      ; 0x0
c000b32c:       e2833001        add     r3, r3, #1      ; 0x1
c000b330:       e59f5228        ldr     r5, [pc, #552]  ; c000b560 <setup_arch+0x660>
c000b334:       e2833000        add     r3, r3, #0      ; 0x0

The first and second adds comprise one translation, the second pair are
a second translation, and as you can see, the compiler scheduled the
loads inbetween.