Hazards shouldn't be an issue on the R10000-series of processors, as they handle all hazards in hardware. So I guess that leaves just finding a replacement for 'synci' on those CPUs, and then maybe relocs could be used on at least IP27, IP28, and IP30 systems (and IP32, if we ever solve the coherency issues there w/ R10K). Not sure what benefit there would be, though. --J On 12/04/2015 03:14, Matt Redfearn wrote: > Hi Joshua, > The patch as it stands uses a couple of MIPS R2 additional instructions to deal > with synchronizing icache. Firstly, the synci instruction to ensure that icache > is in sync with the dcache after the relocated kernel has been written, and the > jr.hb instruction to resolve any hazards created by writing the new kernel > before jumping to it. > > Thanks, > Matt > > On 03/12/15 22:23, Joshua Kinard wrote: >> On 12/03/2015 05:08, Matt Redfearn wrote: >>> This series adds the ability for the MIPS kernel to relocate itself at >>> runtime, optionally to an address determined at random each boot. This >>> series is based on v4.3 and has been tested on the Malta platform. >> [snip] >> >>> * Relocation is currently supported on R2 of the MIPS architecture, >>> 32bit and 64bit. >> Out of curiosity, why is this capability restricted to MIPS R2 and higher? >> IRIX kernels and the 'sash' tool were both relocatable on the older SGI >> platforms. Does the feature, as implemented, rely on R2-specific >> instructions/capabilities, or only due to lack of testing on pre-R2 hardware? >> >> --J >> > > -- Joshua Kinard Gentoo/MIPS kumba@xxxxxxxxxx 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
