Guenter Roeck writes:
> Hi,
>
> my qemu tests of next-20170519 show the following results:
> total: 122 pass: 30 fail: 92
>
> I won't bother listing all of the failures; they are available at
> http://kerneltests.org/builders. I bisected one (openrisc, because
> it gives me some console out
Hi Michael,
> > ppc64 is the only architecture that turns on
> > VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option
> > is extremely high - a context switch microbenchmark using
> > sched_yield() is almost 20% slower.
>
> Running on what? It should all be nop'ed out unless you'r
On Mon, 22 May 2017 14:15:57 +1000
Michael Ellerman wrote:
> Anton Blanchard writes:
>
> > From: Anton Blanchard
> >
> > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE
> > by default. The overhead of this option is extremely high - a context
> > switch microbenchmark u
On 22/05/17 11:32, Daniel Axtens wrote:
Testing the fortified string functions[1] would cause a kernel
panic on boot in test_feature_fixups() due to a buffer overflow
in memcmp.
This boils down to things like this:
extern unsigned int ftr_fixup_test1;
extern unsigned int ftr_fixup_test1_ori
On 22/05/17 11:32, Daniel Axtens wrote:
prom_init is a bit special; in theory it should be able to be
linked separately to the kernel. To keep this from getting too
complex, the symbols that prom_init.c uses are checked.
Fortification adds symbols, and it gets quite messy as it includes
things l
Just FYI, this was written over a year ago and never tested since it
pre-dated KVM support on P9. It's possible the real mode KVM bits have
grown an extra decremented usages since then. If so they will probably
need updating to use the GET_DEC() macro.
On Mon, May 22, 2017 at 1:55 PM, Oliver O'Hal
Anton Blanchard writes:
> From: Anton Blanchard
>
> ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE
> by default. The overhead of this option is extremely high - a context
> switch microbenchmark using sched_yield() is almost 20% slower.
Running on what? It should all be
Nicholas Piggin writes:
> On Mon, 22 May 2017 08:09:19 +1000
> Benjamin Herrenschmidt wrote:
>
>> On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote:
>> > I'd like to take over the r14 register for use as a per-cpu kernel
>> > register similar to the way r13 is used for the paca.
>>
>>
Power ISAv3 extends the width of the decrementer register from 32 bits.
The enlarged register width is implementation dependent, but reads from
these registers are automatically sign extended to produce a 64 bit
output when operating in large mode. The HDEC always operates in large
mode while the D
This series provides arch-specific support for Daniel Micay's
fortified string functions on powerpc.
Fortified string functions provied some compile and run time bounds
checking on commonly used string functions.
It's cool - currently it picks up a lot of random things so it will
require some mor
Testing the fortified string functions[1] would cause a kernel
panic on boot in test_feature_fixups() due to a buffer overflow
in memcmp.
This boils down to things like this:
extern unsigned int ftr_fixup_test1;
extern unsigned int ftr_fixup_test1_orig;
check(memcmp(&ftr_fixup_test1, &ftr_
prom_init is a bit special; in theory it should be able to be
linked separately to the kernel. To keep this from getting too
complex, the symbols that prom_init.c uses are checked.
Fortification adds symbols, and it gets quite messy as it includes
things like panic(). So just don't fortify prom_in
On Mon, 22 May 2017 08:09:19 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote:
> > I'd like to take over the r14 register for use as a per-cpu kernel
> > register similar to the way r13 is used for the paca.
>
> Why not use r13 instead ? We don't n
On Sat, 2017-05-20 at 14:29 +1000, Nicholas Piggin wrote:
> Providing "scv" support to userspace requires kernel support, so it
> must be advertised as independently to the base ISA 3 instruction set.
>
> The darn instruction relies on firmware enablement, so it has been
> decided to split this ou
On Mon, 2017-05-22 at 00:00 +1000, Nicholas Piggin wrote:
> I'd like to take over the r14 register for use as a per-cpu kernel
> register similar to the way r13 is used for the paca.
Why not use r13 instead ? We don't need to access the PACA that often
from C code, I thought we could flip them...
On Sun, May 21, 2017 at 07:57:53PM +0200, Thomas Gleixner wrote:
> On Thu, 18 May 2017, Christoph Hellwig wrote:
> > On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote:
> > > > b) give the union a name (breaks any reference to timer_list->func in C
> > > > code):
> > > >
> > > > +
On Sun, 21 May 2017, Thomas Gleixner wrote:
> On Tue, 16 May 2017, Arnd Bergmann wrote:
> > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote:
> > > Yes, that sounds useful to me as well. As you said it's an independent
> > > but somewhat related change. I can add it to my series, but I'l
On Thu, 18 May 2017, Christoph Hellwig wrote:
> On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote:
> > > b) give the union a name (breaks any reference to timer_list->func in C
> > > code):
> > >
> > > + union {
> > > + void(*func)(struct timer_li
From: Sivakumar Krishnasamy
Date: Fri, 19 May 2017 05:30:38 -0400
...
> Signed-off-by: Sivakumar Krishnasamy
Applied, thanks for the more detailed commit message.
On Tue, 16 May 2017, Arnd Bergmann wrote:
> On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote:
> > Yes, that sounds useful to me as well. As you said it's an independent
> > but somewhat related change. I can add it to my series, but I'll
> > need a suggestions for a good and short name.
I'd like to take over the r14 register for use as a per-cpu kernel
register similar to the way r13 is used for the paca.
r14 being the last non-volatile register gcc allocates, appears with
about 0.5% the frequency as r31 in (static) instructions. I haven't
counted dynamically how many extra spill
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/exception-64s.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index aaee57f0e5ad..3b768cb668e7 100644
--- a/arch/powerpc/inclu
EX_R3 is used only for a small section of the bad stack handler.
Merge it with EX_DAR.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/exception-64s.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arc
EX_LR is used only for a small section of the SLB miss handler.
Merge it with EX_DAR.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/exception-64s.h | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arc
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/exception-64s.h | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 3edcad24684f..e1103dc9d8e8 100644
---
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/exception-64s.h | 30 +++---
arch/powerpc/include/asm/paca.h | 12
2 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/in
The SLB miss handler uses r3 for the faulting address but r12 is
mostly able to be freed up to save r3 in. It just requires SRR1
be reloaded again on error.
It would be more conventional to use r12 for SRR1 (and use r11 to
save r3), but slb_allocate_realmode clobbers r11 and not r12.
Signed-off-b
The EXCEPTION_PROLOG_1 used by SLB miss already saves CTR when the
kernel is built with CONFIG_RELOCATABLE. So it does not have to be
saved and reloaded when branching to slb_miss_realmode. It can be
restored from the PACA as usual.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptio
The EX_DAR save area is only used in exceptional cases. With r3 no
longer clobbered by slb_allocate_realmode, saving faulting address to
EX_DAR can be deferred to those cases.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 13 -
1 file changed, 8 insertions
One fewer registers clobbered by this function means the SLB miss
handler can save one fewer.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/slb_low.S | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/sl
I want to save another register in the PACA, so I had a look at
what we might cut from it first. 3-4 fields are reasonably easy
to remove.
Nicholas Piggin (9):
powerpc/64s: slb_allocate_realmode() preserve r3
powerpc/64s: SLB miss handler avoid saving faulting address into
EX_DAR
powerpc
On Sun, May 21, 2017 at 9:00 AM, Christoph Hellwig wrote:
> On Thu, May 18, 2017 at 10:57:31AM +0200, Arnd Bergmann wrote:
>> How expensive would it be to add another field to timer_list and
>> just have both pointers?
>
> That would add 4/8 bytes to every structure containing a timer,
> so I'd ra
On Thu, May 18, 2017 at 10:57:31AM +0200, Arnd Bergmann wrote:
> How expensive would it be to add another field to timer_list and
> just have both pointers?
That would add 4/8 bytes to every structure containing a timer,
so I'd rather avoid it if possible. But one option might be to
inflict this
33 matches
Mail list logo
