Page MenuHomeFreeBSD

[PowerPC] WIP: PPC64 ifuncs, solve remaining relocatable kernel oddities
Needs ReviewPublic

Authored by bdragon on Jan 13 2020, 8:08 PM.



This isn't quite fully baked yet, and I should probably split it out further.

  • 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 ifunc bits.
  • Add a trick to relocate to the DMAP even on virtual mode OpenFirmware.
  • 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.

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped

Event Timeline

bdragon created this revision.Jan 13 2020, 8:08 PM
bdragon added inline comments.Jan 13 2020, 8:17 PM

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.

bdragon added inline comments.Jan 13 2020, 8:38 PM

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!

bdragon marked 4 inline comments as not done.Jan 13 2020, 8:38 PM
jhibbits added inline comments.Jan 17 2020, 9:00 PM

Might want to update this error as well :)