All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Hari Bathini <hbathini@linux.vnet.ibm.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>,
	Michael Neuling <mikey@neuling.org>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [v2] ppc64/book3s: fix branching to out of line handlers in relocation kernel
Date: Wed, 30 Mar 2016 22:17:23 +1100	[thread overview]
Message-ID: <1459336643.23987.6.camel@ellerman.id.au> (raw)
In-Reply-To: <56FB83C1.7070306@linux.vnet.ibm.com>

On Wed, 2016-03-30 at 13:14 +0530, Hari Bathini wrote:
> 
> Alternatively, how about moving the OOLs handlers that can't be branched with
> LOAD_HANDLER under __end_interrupts. This way we won't be copying more than a
> few absolutely needed handlers.
> 
> STD_RELON_EXCEPTION_HV_OOL(0xe40, emulation_assist)
> .
> .
> STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
> 
> 
> We can leave __end_handlers marker to indicate code that should be part 
> of the first 64K of kernel image.

That might work. But I suspect you will run into issues with ".org backwards",
ie. running out of space in head_64.S

But try it and let me know if it works.

I think we also need to write a script or little C program which looks at the
vmlinux and checks that nothing below __end_whatever does a direct branch. So
that we don't break it again in future.

cheers

  reply	other threads:[~2016-03-30 11:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 18:34 [PATCH v2] ppc64/book3s: fix branching to out of line handlers in relocation kernel Hari Bathini
2016-03-30  0:25 ` [v2] " Michael Ellerman
2016-03-30  7:14   ` Hari Bathini
2016-03-30  7:44     ` Hari Bathini
2016-03-30 11:17       ` Michael Ellerman [this message]
2016-03-30 16:57         ` Hari Bathini
2016-03-30 11:21     ` Michael Ellerman
2016-04-21 13:39 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1459336643.23987.6.camel@ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=hbathini@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mikey@neuling.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.