[PATCH v3] ppc64/book3s: fix branching to out of line handlers in relocation kernel
Gabriel Paubert
paubert at iram.es
Fri Apr 1 17:37:43 AEDT 2016
Hi Michael,
On Fri, Apr 01, 2016 at 05:14:35PM +1100, Michael Ellerman wrote:
> On Wed, 2016-03-30 at 23:49 +0530, Hari Bathini wrote:
> > Some of the interrupt vectors on 64-bit POWER server processors are
> > only 32 bytes long (8 instructions), which is not enough for the full
> ...
> > Let us fix this undependable code path by moving these OOL handlers below
> > __end_interrupts marker to make sure we also copy these handlers to real
> > address 0x100 when running a relocatable kernel. Because the interrupt
> > vectors branching to these OOL handlers are not long enough to use
> > LOAD_HANDLER() for branching as discussed above.
> >
> ...
> > changes from v2:
> > 2. Move the OOL handlers before __end_interrupts marker instead of moving the __end_interrupts marker
> > 3. Leave __end_handlers marker as is.
>
> Hi Hari,
>
> Thanks for trying this. In the end I've decided it's not a good option.
>
> If you build an allmodconfig, and turn on CONFIG_RELOCATABLE, and then look at
> the disassembly, you see this:
>
> c000000000006ffc: 48 00 29 04 b c000000000009900 <.ret_from_except>
>
> c000000000007000 <__end_handlers>:
>
> At 0x7000 we have the FWNMI area, which is fixed and can't move. As you see
> above we end up with only 4 bytes of space between the end of the handlers and
> the FWNMI area.
Nitpicking a bit, if I correctly read the above disassembly and there is an instuction
at 0x6ffc, the free space is exactly 0!
>
> So any tiny change that adds two more instructions prior to 0x7000 will then
> fail to build.
Even one instruction provided I still know how to count.
>
> None of that's your fault, it's just the nature of the code in there, it's very
> space constrained.
Calling it space very constrained makes you win the understatement of the month
award, on April fool's day :-)
Regards,
Gabriel
More information about the Linuxppc-dev
mailing list