Re: [PATCH] powerpc/pasemi: Only the build the pasemi MSI code for PASEMI=y

On Fri, Apr 10, 2015 at 08:38:55PM +1000, Michael Ellerman wrote: > BUT, I can't work out how to tell git-send-email I *always* want to pass -M, > so > I'll probably forget next time :) In your config: -- [diff] renames = true -- but this will do it for all diffs, not just for format-pa

Re: [v2,2/2] powerpc32: add support for csum_add()

On Fri, May 01, 2015 at 08:00:14PM -0500, Scott Wood wrote: > On Tue, 2015-04-28 at 21:01 +0200, christophe leroy wrote: > > The generated code is most likely different on ppc64. I have no ppc64 > > compiler For reference: yes you do. Just add -m64. > Ideal (short of a 64-bit __wsum) would proba

Re: [PATCH v3 2/2] powerpc: add support for csum_add()

On Fri, May 22, 2015 at 02:32:42PM -0500, Scott Wood wrote: > > I'd also have thought that the 64bit C version above would be generally > > 'good'. > > It doesn't generate the addc/addze sequence. At least with GCC 4.8.2, > it does something like: > > mr tmp0, csum > li tm

Re: [PATCH 3/3] powerpc/ftrace: simplify prepare_ftrace_return

On Wed, Sep 24, 2014 at 12:33:07PM +1000, Anton Blanchard wrote: > We are scratching our heads trying to remember details of the issue > right now. In retrospect we should have linked the gcc bugzilla or > gcc commit details in the kernel commit message :) There have been many GCC bugs in this are

Re: [PATCH v2] powerpc: Speed up clear_page by unrolling it

On Thu, Oct 02, 2014 at 03:44:21PM +1000, Anton Blanchard wrote: > This assumes cacheline sizes won't grow beyond 512 bytes or > page sizes wont drop below 1kB, Or a combination of those. > Michael found that some versions of gcc produce quite bad code > (all multiplies), so we give gcc a hand by

Re: [PATCH 03/20] powerpc/47x: Use pm_power_off rather than ppc_md.power_off

On Wed, Oct 01, 2014 at 03:27:49PM +0200, Alexander Graf wrote: > diff --git a/arch/powerpc/platforms/44x/ppc476.c > b/arch/powerpc/platforms/44x/ppc476.c > index 33986c1..7027015 100644 > --- a/arch/powerpc/platforms/44x/ppc476.c > +++ b/arch/powerpc/platforms/44x/ppc476.c > @@ -94,7 +94,7 @@ sta

Re: [PATCH] powerpc: Replace cc constraint in inline assembly with cr0

On Sat, Nov 01, 2014 at 11:42:51AM +1100, Anton Blanchard wrote: > Our inline assembly only clobbers the first condition register field, > but we mark all of them as being clobbered. No, we don't. "cc" has been an alias for cr0 for over twenty two and a half years now; it has never changed meanin

Re: [PATCH] powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

On Thu, Nov 27, 2014 at 09:38:17AM +1100, Michael Ellerman wrote: > On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote: > > I used some 64 bit instructions when adding the 32 bit getcpu VDSO > > function. Fix it. > > Ouch. The symptom is a SIGILL I presume? > > Could we catch this by forcin

Re: [PATCH] powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

On Wed, Nov 26, 2014 at 05:23:18PM -0600, Segher Boessenkool wrote: > GCC has added -many to the assembler flags for over ten years now, so > no that will not work. You can use -mppc or similar with the assembler > if you invoke it correctly (use $(CC) -print-prog-name=as to figure s/

Re: [PATCH] powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

On Wed, Nov 26, 2014 at 05:50:27PM -0600, Peter Bergner wrote: > On Thu, 2014-11-27 at 09:38 +1100, Michael Ellerman wrote: > > On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote: > > > I used some 64 bit instructions when adding the 32 bit getcpu VDSO > > > function. Fix it. > > > > Ouch. T

Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t

On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote: > Here is the design of this patch. Since local_* operations > are only need to be atomic to interrupts (IIUC), patch uses > one of the Condition Register (CR) fields as a flag variable. When > entering the local_*, specific bi

Re: [PATCH] powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

On Thu, Nov 27, 2014 at 11:41:40AM -0600, Peter Bergner wrote: > On Thu, 2014-11-27 at 10:08 -0600, Segher Boessenkool wrote: > > On Wed, Nov 26, 2014 at 05:50:27PM -0600, Peter Bergner wrote: > > > Nope, you don't get a SIGILL when executing 64-bit instructions in >

Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t

On Fri, Nov 28, 2014 at 12:58:55PM +1100, Benjamin Herrenschmidt wrote: > > Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5, > > and it likes to use it very much, it might be more convenient to > > use e.g. CR1 (which is allocated almost last, only before CR0). > > We use CR1 all o

Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t

On Fri, Nov 28, 2014 at 08:27:22AM +0530, Madhavan Srinivasan wrote: > > Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5, > > and it likes to use it very much, it might be more convenient to > > use e.g. CR1 (which is allocated almost last, only before CR0). > > > No. I did not try

Re: [RFC] PPC: MPIC: necessary readback after EOI?

On Wed, Jan 07, 2015 at 03:40:10PM +0100, Benjamin Herrenschmidt wrote: > One way to work around the performance loss for you would be to add some > DT property to indicate to the guest that the read isn't necessary. Or KVM could use a virtual interrupt controller better suited to its needs. Seg

Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL bits in HWCAP2

According to the GCC sources, ISEL is enabled by default for the 8540, 8548, e500mc, e500mc64, e6500 processors. And e5500. POWER7 is said to support it as well. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozla

Re: [PATCH] powerpc: provide __bswapdi2

I did a little digging, and it looks like gcc-4.4 will emit __bswapdi2 calls. Support in rs6000.md appeared 2009-06-25. That's where it was seen. I don't have anything that ancient any more so it didn't show up in my testing, but Al saw it on a Debian system. It should never happen on 32

Re: [PATCH] powerpc: provide __bswapdi2

rlwinm 10,4,8,0x rlwinm 11,3,8,0x rlwimi 10,4,24,0,7 rlwimi 11,3,24,0,7 rlwimi 10,4,24,16,23 rlwimi 11,3,24,16,23 mr 4,11 mr 3,10 Actually, I'd swap the two mr instructions to never have an instruction that uses the

Re: [PATCH SLOF 3/5] disk-label: introduce helper to check fat filesystem

On Mon, Jun 22, 2015 at 01:29:45PM +0530, Nikunj A Dadhania wrote: > +: has-fat-filesystem ( block -- true | false ) > + \ block 0 byte 0-2 is a jump instruction in all FAT > + \ filesystems. "block" there is not a block number, just a host address. So it's not a good name. Maybe do a better

Re: [PATCH SLOF 4/5] disk-label: add support for booting from GPT FAT partition

On Tue, Jun 23, 2015 at 09:34:44AM +0200, Thomas Huth wrote: > > +: load-from-gpt-partition ( [ addr ] -- size | TRUE ) > > What do you mean with addr in square brackets? Is it optional? And "size | TRUE"? The code even returns "false" instead, which usually is a valid size (0). Just always ret

Re: [PATCH SLOF v3 3/5] disk-label: rename confusing "block" word

On Tue, Jun 30, 2015 at 04:31:19PM +0530, Nikunj A Dadhania wrote: > "block" word is not a block number, actually its an allocated host > address. Rename it to disk-buf along with a associated > size(disk-buf-size=4096) for using during allocation/free. > > Also renaming the helper routine read-s

Re: [PATCH SLOF v3 3/5] disk-label: rename confusing "block" word

On Thu, Jul 02, 2015 at 11:17:49AM +0530, Nikunj A Dadhania wrote: > >> "block" word is not a block number, actually its an allocated host > >> address. Rename it to disk-buf along with a associated > >> size(disk-buf-size=4096) for using during allocation/free. > >> > >> Also renaming the helper

Re: [PATCH v2] Caps in not always shift

On Thu, Jul 09, 2015 at 08:00:48AM +0200, Thomas Huth wrote: > > /** > > + * Checks if keypos is a latin key > > + * @param keypos > > + * @return - > > + */ > > +void check_latin(uint8_t keypos) > > + if (keypos > KEYP_LATIN_A || keypos < KEYP_LATIN_Z) { > > + return true; > > + }

Re: [PATCH 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec

On Tue, Jul 07, 2015 at 11:22:08PM -0500, Scott Wood wrote: > > I agree about using labels, but "bcl 20,31,foo" is not the same thing > > as "bl foo". The former is a form of bl that doesn't perturb the link > > stack and is therefore better for performance when you're not going to > > do a matchi

Re: [PATCH] powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*

On Fri, Jul 17, 2015 at 07:15:58PM +1000, Paul Mackerras wrote: > @@ -7,13 +7,22 @@ > > static inline int arch_get_random_long(unsigned long *v) > { > + return 0; > +} > + > +static inline int arch_get_random_int(unsigned int *v) > +{ > + return 0; > +} > + > +static inline int arch_get

Re: [PATCH V3 2/2] powerpc/kexec: Reset HILE before entering target kernel

On Fri, Jul 17, 2015 at 11:53:38AM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2015-07-10 at 15:19 +1000, Samuel Mendoza-Jonas wrote: > > +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_POWERNV) > > + li r3,(FW_FEATURE_OPAL >> 16) > > + rldicr r3,r3,16,63 > > + a

Re: [PATCH V3 2/2] kprobes: Mark OPTPROBES na for powerpc

On Mon, Jul 20, 2015 at 04:24:22PM +0530, Ananth N Mavinakayanahalli wrote: > There is a potential gain to be had with a direct > jump instead of a breakpoint, but the caveats need to be traded off > with the complexity it brings in. > > For now, mark OPTPROBES na for powerpc. If we haven't yet i

Re: [RFC 5/8] powerpc/slb: Add documentation to runtime patching of SLB encoding

On Wed, Jul 22, 2015 at 03:51:03PM +1000, Michael Ellerman wrote: > How about: > > /* >* This function patches either an li or a cmpldi instruction with >* a new immediate value. This relies on the fact that both li >* (which is actually ori) and cmpldi both take a 16

Re: [SLOF PATCH 1/2] fbuffer: Improve invert-region helper

On Tue, Jul 28, 2015 at 12:19:54PM +0200, Thomas Huth wrote: > : invert-region ( addr len -- ) > - 0 ?DO dup dup rb@ -1 xor swap rb! 1+ LOOP drop > -; > - > -: invert-region-x ( addr len -- ) > - /x / 0 ?DO dup dup rx@ -1 xor swap rx! xa1+ LOOP drop > + 2dup or 7 and CASE > + 0 OF 3 rsh

Re: [SLOF] [SLOF PATCH 2/2] fbuffer: Use a smaller cursor

On Wed, Jul 29, 2015 at 01:05:48PM +1000, Alexey Kardashevskiy wrote: > > : fb8-toggle-cursor ( -- ) > > line# fb8-line2addr column# fb8-columns2bytes + > >-char-height 0 ?DO > >+char-height 3 - screen-width screen-depth * * + > >+3 0 ?DO > > Why not just: > > - char-height 0

Re: powerpc: Add an inline function to update HID0

On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote: > > +static inline void update_hid0(unsigned long hid0) > > +{ > > + /* > > +* The HID0 update should at the very least be preceded by a > > +* a SYNC instruction followed by an ISYNC instruction > > +*/ > > + mb();

Re: RFC: Reducing the number of non volatile GPRs in the ppc64 kernel

Hi Anton, On Wed, Aug 05, 2015 at 02:03:00PM +1000, Anton Blanchard wrote: > While looking at traces of kernel workloads, I noticed places where gcc > used a large number of non volatiles. Some of these functions > did very little work, and we spent most of our time saving the > non volatiles to t

Re: [PATCH 1/5] powerpc/pseries: extract of_helpers module

Hi Andy, On Tue, Aug 04, 2015 at 05:36:45PM +0300, Andy Shevchenko wrote: > +struct device_node *pseries_of_derive_parent(const char *path) > +{ > + struct device_node *parent = NULL; > + char *parent_path = "/"; > + size_t parent_path_len = strrchr(path, '/') - path + 1; > + > + /

Re: [PATCH 1/5] powerpc/pseries: extract of_helpers module

On Wed, Aug 05, 2015 at 12:32:55PM +0300, Andy Shevchenko wrote: > > If path doesn't contain any slash this will do interesting things; > > you might want to fix that too while you're at it :-) > > No problem, though it is in the original code. I would do as a separate > patch on top of the series

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > On the 8xx, load latency is 2 cycles and taking branches also takes > 2 cycles. So let's unroll the loop. This is not true for most other 32-bit PowerPC; this patch makes performance worse on e.g. 6xx/7xx/7xxx. Let's not! Seghe

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Wed, Aug 05, 2015 at 09:31:41PM -0500, Scott Wood wrote: > On Wed, 2015-08-05 at 19:30 -0500, Segher Boessenkool wrote: > > On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > > > On the 8xx, load latency is 2 cycles and taking branches also takes > > >

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: > > The original loop was already optimal, as the comment said. > > The comment says that bdnz has zero overhead. That doesn't mean the adde > won't stall waiting for the load result. adde is execution serialising on those cores; it *a

Re: RFC: Reducing the number of non volatile GPRs in the ppc64 kernel

On Mon, Aug 10, 2015 at 02:52:28PM +1000, Anton Blanchard wrote: > Hi Bill, Segher, > > > I agree with Segher. We already know we have opportunities to do a > > better job with shrink-wrapping (pushing this kind of useless > > activity down past early exits), so having examples of code to look >

Re: RFC: Reducing the number of non volatile GPRs in the ppc64 kernel

On Tue, Aug 11, 2015 at 03:08:29PM -0500, Segher Boessenkool wrote: > [snip code] > > After the prologue there are 46 insns executed before the epilogue. > Many of those are conditional branches (that are not executed); it is > all fall-through until it jumps to the "tail&qu

Re: [PATCH 02/20] powerpc/8xx: Map linear kernel RAM with 8M pages

On Wed, Aug 12, 2015 at 03:40:56PM +0200, Christophe Leroy wrote: > /* Insert level 1 index */ > rlwimi r11, r10, 32 - ((PAGE_SHIFT - 2) << 1), (PAGE_SHIFT - 2) << 1, > 29 > lwz r11, (swapper_pg_dir-PAGE_OFFSET)@l(r11)/* Get the > level 1 entry */ > + mtcrr1

Re: error: 'asm' operand has impossible constraints when compiling gromacs 5.1 on PPC64 and PPC64LE with VSX SMD

Hi, On Thu, Aug 20, 2015 at 09:31:07AM +0200, Dominik 'Rathann' Mierzejewski wrote: > /builddir/build/BUILD/gromacs-5.1/src/gromacs/simd/impl_ibm_vsx/impl_ibm_vsx.h:452:80: > error: 'asm' operand has impossible constraints > __asm__ ("xvcvsxwdp %0,%1" : "=ww" (x) : "ww" ((__vector signed int

Re: weird elf header issues, is it binutils or my linker script?

PHDRS { headers PT_PHDR PHDRS ; interp PT_INTERP ; } SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = 0xf200); . = 0xf200 + SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp } So I'm wondering...is this something wro

Re: weird elf header issues, is it binutils or my linker script?

SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = 0xf200); . = 0xf200 + SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp } So I'm wondering...is this something wrong with our linker script, or is there a bug in our binutils? I'm no linker

Re: [PATCH V2 2/5] powerpc, perf: Add basic assembly code to read BHRB entries on POWER8

+/* r3 = n (where n = [0-1023]) + * The maximum number of BHRB entries supported with PPC_MFBHRBE instruction + * is 1024. We have limited number of table entries here as POWER8 implements + * 32 BHRB entries. + */ + +/* .global read_bhrb */ +_GLOBAL(read_bhrb) + cmpldi r3,1023 This

Re: [PATCH 2/2 V7] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx

* Remove A variant of load instruction emulation Why is this? You handle all other simple load insns, there is nothing special about LHA. (I reviewed the V4 email thread, no reason for the chance is given there). Segher ___ Linuxppc-dev mailing li

Re: [PATCH 2/2 V7] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx

* Remove A variant of load instruction emulation Why is this? You handle all other simple load insns, there is nothing special about LHA. (I reviewed the V4 email thread, no reason for the chance is given there). The LHA implementation in V5 was incorrect (didn't sign-extend). The history o

Re: [PATCH 2/2 V7] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx

In former email you doubt whether we need A variant or not. Any particular reason for that? If not should I emulate all the A ARX AU AUX and AX variant? A/AU/AX/AUX are just normal loads, sign-extended instead of zero-extended (so assign -1 to the register loaded). The ARX thing is load-locked,

Re: power and percpu: Could we move the paca into the percpu area?

> Actually, from gcc/config/rs6000.h: > > /* 1 for registers that have pervasive standard uses >and are not available for the register allocator. [snip] > So cr5, which is number 73, is never used by gcc. Not available for RA is not the same thing at all as not used by GCC. For example, GP

Re: power and percpu: Could we move the paca into the percpu area?

On Fri, Jun 13, 2014 at 07:57:08AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2014-06-12 at 07:26 -0500, Segher Boessenkool wrote: > > But, indeed, it does look like GCC doesn't use it. It seems to me > > that > > some ABI forbade userland (or non-libraries or w

Re: power and percpu: Could we move the paca into the percpu area?

> > > So cr5, which is number 73, is never used by gcc. > > > > Not available for RA is not the same thing at all as not used by GCC. > > For example, GPR1 and XER[CA] are also fixed regs. > > Indeed, I should have been more clear, it is never explicitly reserved > by any ABI like GPR1 for the s

Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint

> +/* > + * KVMPPC_INST_BOOK3S_DEBUG is debug Instruction for supporting Software > Breakpoint. > + * Based on PowerISA v2.07, Instruction with opcode 0s will be treated as > illegal > + * instruction. > + */ "primary opcode 0" instead? > +#define OP_ZERO 0x0 Using 0x0 where yo

Re: [PATCH v2] powerpc/mpic: Add DT option to skip readback after EOI

On Tue, Jan 27, 2015 at 03:57:53PM -0600, Scott Wood wrote: > At this point, given the previous discussion, does anyone object to > removing the readback entirely? Do we have any evidence that reading > WHOAMI is effective at addressing whatever problem reading EOI made go > away on the relevant p

Re: [PATCH v1 2/7] AES for PPC/SPE - aes tables

On Mon, Feb 16, 2015 at 02:19:50PM +, David Laight wrote: > From: Markus Stockhausen > > 4K AES tables for big endian > > I can't help feeling that you could give more information about how the > values are generated. ... and an explanation of why this does not open you up to a timing attack

Re: [PATCH 2/3] powerpc: Load Monitor Register Support

Hi, On Mon, Apr 11, 2016 at 01:57:44PM -0500, Jack Miller wrote: > __init_FSCR: > mfspr r3,SPRN_FSCR > + andi. r3,r3,(~FSCR_LM)@L > ori r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB > mtspr SPRN_FSCR,r3 > blr This clears the top 48 bits as well. Shouldn't matter curren

Re: [PATCH] powerpc/ptrace: Fix out of bounds array access warning

On Sun, Apr 24, 2016 at 11:00:06PM -0700, Khem Raj wrote: > gcc-6 correctly warns about a out of bounds access > > arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset > greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' > [-Warray-bounds] > offseto

Re: [PATCH] powerpc/book3s32: Only select PPC_HAVE_PMU on e600

On Fri, Sep 04, 2015 at 08:00:59PM +0200, christophe leroy wrote: > >Plus, it's e300, not e600, that is the exception among 6xx-style cores. > Is it ? I've been looking for special register SIAR (spr 955) in several > 6xx reference manuals. > 82xx doesn't have it, 52xx and 512x don't have it. > I

Re: [PATCH] powerpc/book3s32: Only select PPC_HAVE_PMU on e600

[ it seems my previous mail disappeared down the void ] On Fri, Sep 04, 2015 at 08:00:59PM +0200, christophe leroy wrote: > >Plus, it's e300, not e600, that is the exception among 6xx-style cores. > Is it ? I've been looking for special register SIAR (spr 955) in several > 6xx reference manuals.

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

On Thu, Sep 17, 2015 at 12:50:12PM +1000, Michael Ellerman wrote: > On Wed, 2015-09-16 at 21:54 -0400, Steven Rostedt wrote: > > This could be a symptom and not the problem. What the above shows is > > that ftrace tried to convert the mcount at change_protection but what > > it expected was there w

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

On Thu, Sep 17, 2015 at 04:38:52PM +0200, Thomas Gleixner wrote: > [2.398263] Instruction dump: > [2.401297] 0100 00037000 f000 0001 0a641e09 > acde4823 > [2.409237] 000f 179a7b00 07de2900 03ef1480 <01f78a40> 0001c200 > 6000 9421fff0 Those are

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

On Thu, Sep 17, 2015 at 09:47:39AM +, David Laight wrote: > > It also says "tftp", which is intriguing if nothing else :-) > > Much more likely than the above instruction. > If the address it wass read from is in the dump, look at the entire string. And tell us what network drivers you use, w

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

On Fri, Sep 18, 2015 at 08:01:57PM +1000, Michael Ellerman wrote: > Weird. > > Can you try: > > d690740f22f6 ("powerpc/powernv: Enable LEDS support") > > That is the commit before my merge of Scott's tree, which had all the > Freescale > & 32-bit stuff. > > If that works, it would isolate it

Re: -mprofile-kernel vs. notrace in ppc64(le) Linux kernels

On Sat, Sep 26, 2015 at 04:30:08PM +0200, Torsten Duwe wrote: > As I mentioned earlier this year, it's a bad idea to call _mcount from > MMU helper functions (e.g. hash_page...), when the profiling/tracing/ > live-patching/whatever framewok might in turn cause another such fault. > Jikos suggested

Re: Missing operand for tlbie instruction on Power7

On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote: > >> -0: tlbie r4; \ > >> +0: tlbie r4, 0; \ > > > > This isn't correct. With POWER7 and later (which this compile > > is, since it's on LE), the tlbie instruction takes

Re: Missing operand for tlbie instruction on Power7

On Fri, Oct 02, 2015 at 09:24:46PM -0500, Peter Bergner wrote: > > > Ok, than we can just zero out r5 for example and use it in tlbie as RS, > > > right? > > > > That won't assemble _unless_ your assembler is in POWER7 mode. It also > > won't do the right thing at run time on older machines. > >

Re: Missing operand for tlbie instruction on Power7

On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote: > > It's also worth noting that the __flush_power7 uses tlbiel instead of tlbie. > > Yeah that's a good point. It's not clear if the swsusp code wants to a local > or > a global invalidate. If I read the code right, this is called

Re: [PATCH] powerpc/ps3: Quieten the build when building ps3

On Mon, Oct 19, 2015 at 03:53:22PM +1100, Michael Ellerman wrote: > The boot wrapper uses dd when building for ps3, which annoyingly tells > us in great detail what it's doing, eg: > > 512+0 records in > 512+0 records out > 512 bytes (512 B) copied, 0.000802129 s, 638 kB/s > 512+0 records

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote: > Why is GCC building ppc64 object files but telling the linker --oformat elf32- > powerpcle? Are different options somehow being passed to GCC in one case > versus the other? This was changed for GCC 6 in ,

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

On Fri, Nov 06, 2015 at 04:55:49PM -0600, Segher Boessenkool wrote: > On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote: > > Why is GCC building ppc64 object files but telling the linker --oformat > > elf32- > > powerpcle? Are different options somehow being pass

Re: Crypto/nx842: Ignore invalid XER[S0] return error

On Fri, Dec 11, 2015 at 07:30:29PM -0800, Haren Myneni wrote: > NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is > nothing to do with NX request. On powerpc, XER[S0] will be set if > overflow in FPU and stays until another floating point operation is > executed. Since this bit ca

Re: Crypto/nx842: Ignore invalid XER[S0] return error

On Sat, Dec 12, 2015 at 03:01:26PM -0800, Haren Myneni wrote: > On 12/12/2015 12:43 AM, Segher Boessenkool wrote: > > On Fri, Dec 11, 2015 at 07:30:29PM -0800, Haren Myneni wrote: > >> NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is > >> nothin

Re: [RFC 1/1] powerpc: legacy serial port use device tree cell-index property

On Wed, Nov 25, 2015 at 10:46:49AM -0800, Curt Brune wrote: > + /* Check if the ports have an ordering, defined by 'cell-index' */ > + if (((indexp = (u32*)of_get_property(np, "cell-index", &len)) != NULL) > && > + (len == sizeof(u32))) > + index = *indexp; > + >

Re: [RFC 1/1] powerpc: legacy serial port use device tree cell-index property

On Wed, Dec 30, 2015 at 08:36:01AM -0800, Curt Brune wrote: > > What does this do if the value in cell-index is a duplicate. or the port > > with that number is already created some other way? Are the numbers in > > cell-index global anyway, or relative to some parent device (I couldn't > > find t

Re: [PATCH] powerpc: Enable VMX copy on PPC970 (G5)

On Thu, Jan 21, 2016 at 11:25:27AM +1100, Michael Ellerman wrote: > There's no reason I'm aware of that the VMX copy loop shouldn't work on > PPC970. And in fact it seems to boot and generally be happy. But is it faster? Segher ___ Linuxppc-dev mailing

Re: [PATCH 2/6] ptrace: introduce ptrace_syscall_enter to consolidate PTRACE_SYSEMU handling

On Mon, Mar 04, 2019 at 10:46:43AM +, Sudeep Holla wrote: > On Mon, Mar 04, 2019 at 08:03:47AM +, Haibo Xu (Arm Technology China) > wrote: > > On 2019/3/1 2:32, Sudeep Holla wrote: > > > +long ptrace_syscall_enter(struct pt_regs *regs) > > > +{ > > > +#ifdef TIF_SYSCALL_EMU > > > + if (tes

Re: [PATCH] powerpc/6xx: fix setup and use of SPRN_PGDIR for hash32

On Fri, Mar 08, 2019 at 07:05:22AM +, Christophe Leroy wrote: > Not only the 603 but all 6xx need SPRN_PGDIR to be initialised at > startup. This patch move it from __setup_cpu_603() to start_here() > and __secondary_start(), close to the initialisation of SPRN_THREAD. I thought you meant an S

Re: bpf jit PPC64 (BE) test_verifier PTR_TO_STACK store/load failure

Hi! On Wed, Mar 13, 2019 at 12:54:16PM +0200, Yauheni Kaliuta wrote: > This is because of the handling of the +2 offset. The low two bits of instructions with primary opcodes 58 and 62 are part of the opcode, not the offset. These instructions can not have offsets with the low two bits non-zero.

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

all ancient history by now, and good riddance :-) > Signed-off-by: Joel Stanley Acked-by: Segher Boessenkool Segher

Re: [PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

ifted > + * right to compare the appropriate bits. >*/ > + clrldi r6,r4,(64-12) // r6 = r4 & 0xfff You can just write rlwinm r6,r4,0,0x0fff if that is clearer? Or do you still want a comment with that :-) > + cmpdi r6,0xff8 > + bgt .Lshort Reviewed-by: Segher Boessenkool Segher

Re: [PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote: > Segher Boessenkool writes: > > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote: > >> + clrldi r6,r4,(64-12) // r6 = r4 & 0xfff > > > > You can just write > > rlwinm

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Tue, Mar 26, 2019 at 07:55:33AM +, Christophe Leroy wrote: >STACK off0x vaddr 0x paddr 0x align 2**4 > filesz 0x memsz 0x flags rwx You need to prevent this one somehow. What object file forces this? Setting the program headers manu

Re: [PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

On Tue, Mar 26, 2019 at 08:18:07PM +1100, Michael Ellerman wrote: > Segher Boessenkool writes: > > On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote: > >> Segher Boessenkool writes: > >> > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wro

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote: > > > Le 26/03/2019 à 19:19, Segher Boessenkool a écrit : > >On Tue, Mar 26, 2019 at 07:55:33AM +, Christophe Leroy wrote: > >>STACK off0x vaddr 0x paddr 0x align 2

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Tue, Mar 26, 2019 at 03:12:31PM -0500, Segher Boessenkool wrote: > On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote: > > > > > > Le 26/03/2019 à 19:19, Segher Boessenkool a écrit : > > >On Tue, Mar 26, 2019 at 07:55:33AM +, Christophe Le

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Tue, Mar 26, 2019 at 05:29:43PM -0500, Segher Boessenkool wrote: > On Tue, Mar 26, 2019 at 03:12:31PM -0500, Segher Boessenkool wrote: > > On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote: > > > > > > > > > Le 26/03/2019 à 19:19, Segher Boes

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Wed, Mar 27, 2019 at 07:40:32AM +0100, Christophe Leroy wrote: > Le 26/03/2019 à 23:29, Segher Boessenkool a écrit : > >I tried to reproduce this. It does not fail with a ppc6xx_defconfig > >build, and mpc885_ads_defconfig fails with > > So far, the only defconfig

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Wed, Mar 27, 2019 at 07:47:55AM -0500, Segher Boessenkool wrote: > On Wed, Mar 27, 2019 at 07:40:32AM +0100, Christophe Leroy wrote: > > Le 26/03/2019 à 23:29, Segher Boessenkool a écrit : > > >I tried to reproduce this. It does not fail with a ppc6xx_defconf

Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds

On Thu, Mar 28, 2019 at 07:19:57AM +0100, Christophe Leroy wrote: > Le 27/03/2019 à 19:21, Segher Boessenkool a écrit : > >Yeah, okay, we should have some PHDRS statement here still. You can drop > >the dummy segment, and the notes segment as well, or you can keep the notes > &g

Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

Hi! On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote: > - NOTES :kernel :notes > + NOTES I think this still need to be NOTES :kernel or the linker will complain. Did you try to build ppc64_defconfig? (And I do not know if there are any tools that expect the notes i

Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?

Hi! On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote: > I was working on some scaling code that can benefit from 64x64->128-bit > multiplies. GCC supports an __int128 type on processors with hardware > support (including z/Arch and MIPS64), but the support was broken on > early comp

Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?

On Sat, Mar 30, 2019 at 09:00:15AM +1300, Michael Cree wrote: > It does move the umulh inside the loop but that seems sensible since > the use of unlikely() implies that the loop is unlikely to be taken > so on average it would be a good bet to start the calculation of > umulh earlier since it has

Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?

On Sat, Mar 30, 2019 at 11:28:21AM +, George Spelvin wrote: > >> I like that the MIPS code leaves the high half of the product in > >> the hi register until it tests the low half; I wish PowerPC would > >> similarly move the mulhdu *after* the loop, > > > The MIPS code has the multiplication i

Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?

On Sat, Mar 30, 2019 at 10:30:23AM +, George Spelvin wrote: > For s390, that was added on 24 March 2017 by > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246457 > which is part of GCC 7. > > It also only applies to TARGET_ARCH12, which I am guessing > corresponds to HAVE_MARCH_ZEC12_

Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

Hi Joel, On Thu, Apr 04, 2019 at 12:17:40PM +, Joel Stanley wrote: > On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool > wrote: > > On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote: > > > - NOTES :kernel :notes > > > + NOTES > &g

Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5)

On Mon, Mar 02, 2020 at 09:51:44PM +1100, Michael Ellerman wrote: > Linus Torvalds writes: > > Michael, what tends to be the triggers for people using > > PPC_DISABLE_WERROR? Do you have reports for it? > > My memory is that we have had very few reports of it actually causing > problems. But I do

Re: eh_frame confusion

On Mon, Mar 02, 2020 at 11:56:05AM +0100, Rasmus Villemoes wrote: > I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7 > to gcc-8 all object files now end up having .eh_frame section. Since GCC 8, we enable -fasynchronous-unwind-tables by default for PowerPC. See https://gcc

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

t;? It is just a name after all, it is version 1 in all three version fields in the ELF headers! Anyway, looks like it will work, let's see where this goes :-) Reviewed-by: Segher Boessenkool Segher

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

On Thu, Mar 05, 2020 at 01:34:22PM +1000, Nicholas Piggin wrote: > Segher Boessenkool's on March 4, 2020 9:09 am: > >> +override flavour := linux-ppc64v2 > > > > That isn't a good name, heh. This isn't "v2" of anything... Spell out > > the name "ELFv2"? Or as "elfv2"? It is just a name after a

Re: [PATCH 2/2] powerpc: Suppress .eh_frame generation

all in assembly. That may change, but it is easy to change again for just the VDSOs. > Reported-by: Rasmus Villemoes > Signed-off-by: Naveen N. Rao Reviewed-by: Segher Boessenkool Thanks! Segher

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

On Sat, Mar 07, 2020 at 10:58:54AM +1000, Nicholas Piggin wrote: > Segher Boessenkool's on March 5, 2020 8:55 pm: > > That name looks perfect to me. You'll have to update REs expecting the > > arch at the end (like /le$/), but you had to already I think? > > le$ is still okay for testing ppc64le,

Re: [PATCH v2] powerpc/perf: Use SIER_USER_MASK while updating SPRN_SIER for EBB events

On Fri, Mar 13, 2020 at 01:49:07PM -0400, Athira Rajeev wrote: > Sampled instruction address register (SIER), is a PMU register, SIER stands for "Sampled Instruction Event Register", instead. With that change, your patch is totally clear :-) Segher

  1   2   3   4   5   6   7   8   9   10   >