Nice, LGTM.

Looks good, thanks for fixing this.
I've tested this on QEMU, both with and without huge pages and it worked fine.

This is pretty old and it seems the issue that this change was supposed to fix was already fixed in a proper way quite some time ago.

The change itself LGTM.

LGTM. Tested on ppcdevref.

@git_bdragon.rtk0.net, I haven't tested your last revision, but Alfredo and I have been using your previous revision for more than a month, both in ELFv1 environments as in ELFv2, with no issues so far, and it is essential for the ELFv2 transition on PPC.

In D20119#433679, @jhibbits wrote:

The 64-bit Book-E pmap overhead is around 32kB (12 bits worth of PP2D_NENTRIES, so 4096 8-byte entries), and 4kB on 32-bit. This is not small by any stretch, and I do want to rework it, and plan to over the next couple months. For now I can #ifdef within the union (I do want to keep it a union, so that we can eventually have a GENERIC that boots on both AIM and Book-E).

Overall this change looks good to me, but I'm worried with the union of structs parts (see comment below).

I guess now this revision is waiting only for @gromero_br.ibm.com approval, right?

@alfredo.junior_eldorado.org.br and I found out that a kernel linked with lld won't boot if the .toc section is merged into .got.
Also note that the ldscript change was part of the original patch by @git_bdragon.rtk0.net, but was removed when merging with @jhibbits changes (D19574).

• Do not ommit .toc section when linking

Ok, thanks for the explanation, then it LGTM.

Patch updated, merged with parts already commited

Looks good overall, but check the comments below.

LGTM.
I see this is basically a subset of D19352, with the exception of booke/locore.S, right?
BTW, I need to come back to D19352 and refactor it.

In D19634#420545, @jhibbits wrote:

I'm on the fence between interrupt.c and trap.c. I put it in interrupt.c for the following reasons:
a) Avoid duplicating code between the user and kernel checks
b) Avoid enabling the EE bit when handling the HMI
Neither are critical, I think, so if there are strong feelings one way or another I can yield to it.

The code looks good to me.
But I'm not sure if it is better to handle this in interrupt.c or trap.c. Why do you think it fits better in interrupt.c?

I've confirmed that a kernel with this change compiles fine with base gcc + ld, and works fine on both pseries (qemu+kvm) and powernv (power8 machine).

Approving the minor '-' signal move to unblock this change.

@jhibbits, is this change good to go now? It would be nice to get DDB working on boot.