Re: [PATCH v3] ppc64/book3s: fix branching to out of line handlers in relocation kernel

[Gabriel Paubert <paubert@iram.es>]

    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