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.

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.

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

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

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.

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.

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.

This memcpy is for alignment reasons.

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.

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!

Might want to update this error as well :)

I should take this block back out before committing.

I need to remove this block before committing.

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