Re: [v4, 2/3] ppc64/book3s: make some room for common interrupt vector code
On 04/15/2016 06:29 PM, Michael Ellerman wrote:
On Fri, 2016-04-15 at 21:06 +1000, Michael Ellerman wrote:
Hi Hari,
Thanks for persisting with this.
On Thu, 2016-07-04 at 21:58:50 UTC, Hari Bathini wrote:
With the previous patch, we choke out whatever little space is left
below 0x7000 (FWNMI hard block) while there is a hole of ~1400 bytes
below __end_interrupts marker when CONFIG_CBE_RAS is disabled.
Considering CONFIG_CBE_RAS is not enabled by default for BOOK3S, this
is not a desirable scenario especially when we have to worry about
each additional instruction that goes below 0x7000.
Memory region from 0x1800 to 0x4000 is dedicated for common interrupt
vector code. Also, we never hit an interrupt below 0x300 when IR=DR=1
implying memory region between 0x4000 to 0x4300 can also be used for
common interrupt vector code. So, we can effectively use memory region
between 0x1800 to 0x4300 for common interrupt vector code.
On Power9 the system-call-vectored instruction will use the region at 0x3000, so
moving code into that space is not a good long term plan.
I'll take your v2 and put it in next next week.
I'll add this fixes line, which I think is correct:
Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers")
Yeah. Thanks!
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4, 2/3] ppc64/book3s: make some room for common interrupt vector code
On Fri, 2016-04-15 at 21:06 +1000, Michael Ellerman wrote:
> Hi Hari,
>
> Thanks for persisting with this.
>
> On Thu, 2016-07-04 at 21:58:50 UTC, Hari Bathini wrote:
> > With the previous patch, we choke out whatever little space is left
> > below 0x7000 (FWNMI hard block) while there is a hole of ~1400 bytes
> > below __end_interrupts marker when CONFIG_CBE_RAS is disabled.
> > Considering CONFIG_CBE_RAS is not enabled by default for BOOK3S, this
> > is not a desirable scenario especially when we have to worry about
> > each additional instruction that goes below 0x7000.
> >
> > Memory region from 0x1800 to 0x4000 is dedicated for common interrupt
> > vector code. Also, we never hit an interrupt below 0x300 when IR=DR=1
> > implying memory region between 0x4000 to 0x4300 can also be used for
> > common interrupt vector code. So, we can effectively use memory region
> > between 0x1800 to 0x4300 for common interrupt vector code.
>
> On Power9 the system-call-vectored instruction will use the region at 0x3000,
> so
> moving code into that space is not a good long term plan.
>
> I'll take your v2 and put it in next next week.
I'll add this fixes line, which I think is correct:
Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers")
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4, 2/3] ppc64/book3s: make some room for common interrupt vector code
Hi Hari, Thanks for persisting with this. On Thu, 2016-07-04 at 21:58:50 UTC, Hari Bathini wrote: > With the previous patch, we choke out whatever little space is left > below 0x7000 (FWNMI hard block) while there is a hole of ~1400 bytes > below __end_interrupts marker when CONFIG_CBE_RAS is disabled. > Considering CONFIG_CBE_RAS is not enabled by default for BOOK3S, this > is not a desirable scenario especially when we have to worry about > each additional instruction that goes below 0x7000. > > Memory region from 0x1800 to 0x4000 is dedicated for common interrupt > vector code. Also, we never hit an interrupt below 0x300 when IR=DR=1 > implying memory region between 0x4000 to 0x4300 can also be used for > common interrupt vector code. So, we can effectively use memory region > between 0x1800 to 0x4300 for common interrupt vector code. On Power9 the system-call-vectored instruction will use the region at 0x3000, so moving code into that space is not a good long term plan. I'll take your v2 and put it in next next week. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
