[PowerPC] IFUNC kernel support, fix relocatable kernel oddities for ppc64

[bdragon]

Summary

This is almost ready, pending some patches it depends on.

• Change relocatable kernel related #ifdefs to be RELOCATABLE_KERNEL instead of powerpc, to allow for other platforms to use relocatable kernels in the future.
• Add powerpc64 and powerpc32 ifunc bits.
• Add a trick to relocate to the DMAP even on virtual mode 64 bit OpenFirmware. (32 bit currently runs identity-mapped and does not need this ability)
• Remove DB_STOFFS hack so we start getting a real picture of what's going on with memory addresses on PPC64.
• Fix symbol relocation to work as intended by relocating the symbol table values. (XXX need to check if there's a more straightforward way to process this.)
• Add a trick to allow self-loading symbol tables on powernv by setting the initrd to load the kernel binary.

[bdragon]

sys/powerpc/aim/locore64.S

238 ↗

(On Diff #66697)

I would love to know if anyone has any reason NOT to do this.

As far as I can tell, 64 bit AIM using virtual mode OpenFirmware = Power Macintosh G5, full stop. Everything else that I'm aware of uses real mode OF and doesn't have to do this in the first place.

255 ↗

(On Diff #66697)

This is actually the reason that those OFW decrementer traps happen -- Apple forgot to install the segment traps, so if there's a segment fault, it ends up faulting in a loop on the first instruction until the decrementer times out.

I haven't tested this, because when I tried it, it didn't work. I later realized that the reason it didn't work was that I'd forgotten to icbi it.

[bdragon]

sys/powerpc/aim/locore64.S

222 ↗

(On Diff #66697)

need to add to comment: "We exit real mode at the end of __restartkernel when we rfid."

229 ↗

(On Diff #66697)

I should probably be loading the SLBE relevant bits of DMAP_BASE_ADDRESS instead of hardcoding it here.

247 ↗

(On Diff #66697)

I can probably tighten up on these syncs more than this. But meh, I'd rather not have to pore over openfirmware .register output any more than I have to.

268 ↗

(On Diff #66697)

Another way to do this is to check if the entire trap area for the trap is empty, and if so, copy the 0x?00-0x?7f bytes in.

sys/powerpc/include/db_machdep.h

89 ↗

(On Diff #66697)

Need to *actually* remove this code in the final version. As well as probably cleaning up the hack in the rest of the kernel code, I am pretty sure that the only reason it existed was for ppc64.

sys/powerpc/ofw/ofw_initrd.c

99 ↗

(On Diff #66697)

This memcpy is for alignment reasons.

sys/powerpc/powerpc/elf64_machdep.c

347 ↗

(On Diff #66697)

Current kernel ABI for ifuncs doesn't utilize parameter passing like the user ifuncs do.

If it turns out to be problematic, we should add cpu_features / cpu_features2 as well as info about what mmu is installed.

sys/powerpc/powerpc/machdep.c

367 ↗

(On Diff #66697)

Nobody had to handle this previously because none of the other platforms had relocatable kernels and ours had the DB_STOFFS hack.
Turning off the hack was illuminating as to what was actually going on!

[jhibbits]

sys/conf/kern.pre.mk

162 ↗

(On Diff #66697)

Might want to update this error as well :)

[bdragon]

• Extend ifunc support to ppc32 (requires the ppc32 lld10 patchset, will post them for review shortly)

[bdragon]

Updating comments.

sys/powerpc/aim/locore64.S

254 ↗

(On Diff #69622)

I should take this block back out before committing.

sys/powerpc/powerpc/machdep.c

752 ↗

(On Diff #69622)

I need to remove this block before committing.

For now, it's handy for verifying ifunc operation.

[jhibbits]

Any update to this? I'm eager to IFUNC-ify pmap, maybe squeak in a little performance boost from it.