Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread Segher Boessenkool
On Thu, Sep 10, 2020 at 03:31:53PM +, David Laight wrote: > > > asm volatile ("" : "+r" (eax)); > > > // So here eax must contain the value set by the "x" instructions. > > > > No, the register eax will contain the value of the eax variable. In the > > asm; it might well be there

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread Segher Boessenkool
On Wed, Sep 09, 2020 at 02:33:36PM -0700, Linus Torvalds wrote: > On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool > wrote: > > > > It will not work like this in GCC, no. The LLVM people know about that. > > I do not know why they insist on pushing this, being incompa

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread Segher Boessenkool
On Thu, Sep 10, 2020 at 12:26:53PM +, David Laight wrote: > Actually this is pretty sound: > __label__ label; > register int eax asm ("eax"); > // Ensure eax can't be reloaded from anywhere > // In particular it can't be reloaded after the asm goto line > asm

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread Segher Boessenkool
On Thu, Sep 10, 2020 at 09:26:28AM +, David Laight wrote: > From: Christophe Leroy > > Sent: 10 September 2020 09:14 > > > > Le 10/09/2020 à 10:04, David Laight a écrit : > > > From: Linus Torvalds > > >> Sent: 09 September 2020 22:34 > > >&

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-09 Thread Segher Boessenkool
On Wed, Sep 09, 2020 at 10:31:34AM -0700, Linus Torvalds wrote: > And apparently there are people working on this on the gcc side too, > so it won't just be clang-specific. Nor kernel-specific in that Nick > tells me some other projects are looking at using that asm goto with > outputs too. It

Re: [PATCH 2/2] powerpc/vdso32: link vdso64 with linker

2020-09-02 Thread Segher Boessenkool
On Wed, Sep 02, 2020 at 05:43:03PM +0200, Christophe Leroy wrote: > >Try with a newer ld? If it still happens with current versions, please > >open a bug report? https://sourceware.org/bugzilla > > Yes it works with 2.30 and 2.34 Ah okay, I missed this part. > But minimum for building kernel

Re: [PATCH 2/2] powerpc/vdso32: link vdso64 with linker

2020-09-02 Thread Segher Boessenkool
Hi! On Wed, Sep 02, 2020 at 06:46:45AM +, Christophe Leroy wrote: > ld crashes: > > LD arch/powerpc/kernel/vdso32/vdso32.so.dbg > /bin/sh: line 1: 23780 Segmentation fault (core dumped) > ppc-linux-ld -EB -m elf32ppc -shared -soname linux-vdso32.so.1 > --eh-frame-hdr

Re: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread Segher Boessenkool
On Mon, Aug 24, 2020 at 07:54:07PM +0800, Guohua Zhong wrote: > >> Yet, I have noticed that there is no checking of 'base' in these functions. > >> But I am not sure how to check is better.As we know that the result is > >> undefined when divisor is zero. It maybe good to print error and dump >

Re: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Segher Boessenkool
On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote: > Yet, I have noticed that there is no checking of 'base' in these functions. > But I am not sure how to check is better.As we know that the result is > undefined when divisor is zero. It maybe good to print error and dump stack. >

Re: [PATCH] sfc_ef100: Fix build failure on powerpc

2020-08-13 Thread Segher Boessenkool
On Thu, Aug 13, 2020 at 02:39:10PM +, Christophe Leroy wrote: > ppc6xx_defconfig fails building sfc.ko module, complaining > about the lack of _umoddi3 symbol. > > This is due to the following test > > if (EFX_MIN_DMAQ_SIZE % reader->value) { > > Because reader->value is u64.

Re: [PATCH v3 2/2] powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()

2020-08-12 Thread Segher Boessenkool
On Wed, Aug 12, 2020 at 12:25:17PM +, Christophe Leroy wrote: > Enable pre-update addressing mode in __get_user_asm() and __put_user_asm() > > Signed-off-by: Christophe Leroy > --- > v3: new, splited out from patch 1. It still looks fine to me, you can keep my Reviewed-by: :-) Segher

Re: [PATCH v2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-08-12 Thread Segher Boessenkool
On Wed, Aug 12, 2020 at 02:32:51PM +0200, Christophe Leroy wrote: > Anyway, it seems that GCC doesn't make much use of the "m<>" and the > pre-update form. GCC does not use update form outside of inner loops much. Did you expect anything else? > Most of the benefit of flexible addressing seems

Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-08-06 Thread Segher Boessenkool
Hi! On Thu, Aug 06, 2020 at 12:03:33PM +1000, Michael Ellerman wrote: > Segher Boessenkool writes: > > On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote: > >> Christophe Leroy writes: > >> > Indeed, 32-bit doesn't have a redzone, so I believe

Re: [PATCH v10 2/5] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-08-05 Thread Segher Boessenkool
Hi! On Wed, Aug 05, 2020 at 06:51:44PM +0200, Christophe Leroy wrote: > Le 05/08/2020 à 16:03, Segher Boessenkool a écrit : > >On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote: > >>+/* > >>+ * The macros sets two stack frames, one for the caller

Re: [PATCH v10 2/5] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-08-05 Thread Segher Boessenkool
Hi! On Wed, Aug 05, 2020 at 04:40:16PM +, Christophe Leroy wrote: > >It cannot optimise it because it does not know shift < 32. The code > >below is incorrect for shift equal to 32, fwiw. > > Is there a way to tell it ? Sure, for example the &31 should work (but it doesn't, with the GCC

Re: [PATCH v10 2/5] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-08-05 Thread Segher Boessenkool
Hi! On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote: > Provide vdso_shift_ns(), as the generic x >> s gives the following > bad result: > > 18: 35 25 ff e0 addic. r9,r5,-32 > 1c: 41 80 00 10 blt 2c > 20: 7c 64 4c 30 srw r4,r3,r9 > 24: 38 60 00 00

Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-08-05 Thread Segher Boessenkool
Hi! On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack > > frame whenever it has anything to same. > > Yeah OK that would explain it. > > > Here is what I have in libc.so: > > >

Re: [PATCH v2 15/16] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

2020-08-03 Thread Segher Boessenkool
On Mon, Aug 03, 2020 at 03:57:11PM +1000, Michael Ellerman wrote: > > I would assume the function should still be generated since those checks > > are relevant, just the return value is bogus. > > Yeah, just sometimes missing warnings boil down to the compiler eliding > whole sections of code, if

Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Segher Boessenkool
On Wed, Jul 29, 2020 at 03:44:56PM -0400, Vladis Dronov wrote: > > > Certain warnings are emitted for powerpc code when building with a gcc-10 > > > toolset: > > > > > > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch > > > in > > > reference from the function

Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Segher Boessenkool
On Wed, Jul 29, 2020 at 03:37:41PM +0200, Vladis Dronov wrote: > Certain warnings are emitted for powerpc code when building with a gcc-10 > toolset: > > WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in > reference from the function remove_pmd_table() to the

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

2020-07-23 Thread Segher Boessenkool
On Thu, Jul 23, 2020 at 09:58:55PM +0200, pet...@infradead.org wrote: > asm ("addb %[val], %b[var];" >"cmovc %[sat], %[var];" >: [var] "+r" (tmp) >: [val] "ir" (val), [sat] "r" (sat) >); "var" (operand 0) needs an earlyclobber ("sat"

Re: [PATCH] powerpc/boot: Use address-of operator on section symbols

2020-07-20 Thread Segher Boessenkool
Hi! On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote: > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor > wrote: > > /* If we have an image attached to us, it overrides anything > > * supplied by the loader. */ > > - if (_initrd_end > _initrd_start) { >

Re: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

2020-07-20 Thread Segher Boessenkool
On Mon, Jul 20, 2020 at 03:10:41PM -0500, Segher Boessenkool wrote: > On Mon, Jul 20, 2020 at 11:39:56AM +0200, Laurent Dufour wrote: > > Le 16/07/2020 à 10:32, Ram Pai a écrit : > > >+ if (is_secure_guest()) {\ > > >+ __

Re: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

2020-07-20 Thread Segher Boessenkool
On Mon, Jul 20, 2020 at 11:39:56AM +0200, Laurent Dufour wrote: > Le 16/07/2020 à 10:32, Ram Pai a écrit : > >+if (is_secure_guest()) {\ > >+__asm__ __volatile__("mfsprg0 %3;" \ > >+"lnia %2;"

Re: Failure to build librseq on ppc

2020-07-09 Thread Segher Boessenkool
On Thu, Jul 09, 2020 at 01:56:19PM -0400, Mathieu Desnoyers wrote: > > Just to make sure I understand your recommendation. So rather than > > hard coding r17 as the temporary registers, we could explicitly > > declare the temporary register as a C variable, pass it as an > > input operand to the

Re: Failure to build librseq on ppc

2020-07-09 Thread Segher Boessenkool
On Thu, Jul 09, 2020 at 01:42:56PM -0400, Mathieu Desnoyers wrote: > > That works fine then, for a testcase. Using r17 is not a great idea for > > performance (it increases the active register footprint, and causes more > > registers to be saved in the prologue of the functions, esp. on older > >

Re: Failure to build librseq on ppc

2020-07-09 Thread Segher Boessenkool
On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote: > > What protects r17 *after* this asm statement? > > As discussed in the other leg of the thread (with the code example), > r17 is in the clobber list of all asm statements using this macro, and > is used as a temporary register

Re: Failure to build librseq on ppc

2020-07-09 Thread Segher Boessenkool
On Thu, Jul 09, 2020 at 09:33:18AM -0400, Mathieu Desnoyers wrote: > > The way this all uses r17 will likely not work reliably. > > r17 is only used as a temporary register within the inline assembler, and it > is > in the clobber list. In which scenario would it not work reliably ? This isn't

Re: powerpc: Incorrect stw operand modifier in __set_pte_at

2020-07-08 Thread Segher Boessenkool
On Wed, Jul 08, 2020 at 06:16:54PM +0200, Christophe Leroy wrote: > Le 08/07/2020 à 16:45, Mathieu Desnoyers a écrit : > >Reviewing use of the patterns "Un%Xn" with lwz and stw instructions > >(where n should be the operand number) within the Linux kernel led > >me to spot those 2 weird cases: > >

Re: Failure to build librseq on ppc

2020-07-08 Thread Segher Boessenkool
On Wed, Jul 08, 2020 at 08:01:23PM -0400, Mathieu Desnoyers wrote: > > > #define RSEQ_ASM_OP_CMPEQ(var, expect, label) > > > \ > > > LOAD_WORD "%%r17, %[" __rseq_str(var) "]\n\t" > > > \ > > > > The way this hardcodes r17

Re: Failure to build librseq on ppc

2020-07-08 Thread Segher Boessenkool
On Wed, Jul 08, 2020 at 10:32:20AM -0400, Mathieu Desnoyers wrote: > > As far as I can see, %U is mentioned in > > https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html in the > > powerpc subpart, at the "m" constraint. > > Yep, I did notice it, but mistakenly thought it was only needed for

Re: Failure to build librseq on ppc

2020-07-08 Thread Segher Boessenkool
Hi! On Wed, Jul 08, 2020 at 10:00:01AM -0400, Mathieu Desnoyers wrote: > >> So perhaps you have code like > >> > >> int *p; > >> int x; > >> ... > >> asm ("lwz %0,%1" : "=r"(x) : "m"(*p)); > > > > We indeed have explicit "lwz" and "stw" instructions in there. > > > >> > >> where that last

Re: Failure to build librseq on ppc

2020-07-08 Thread Segher Boessenkool
Hi! On Wed, Jul 08, 2020 at 10:27:27PM +1000, Michael Ellerman wrote: > Segher Boessenkool writes: > > You'll have to show the actual failing machine code, and with enough > > context that we can relate this to the source code. > > > > -save-temps helps, o

Re: Failure to build librseq on ppc

2020-07-07 Thread Segher Boessenkool
Hi! On Tue, Jul 07, 2020 at 03:17:10PM -0400, Mathieu Desnoyers wrote: > I'm trying to build librseq at: > > https://git.kernel.org/pub/scm/libs/librseq/librseq.git > > on powerpc, and I get these errors when building the rseq basic > test mirrored from the kernel selftests code: > >

Re: [PATCH v2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-06-30 Thread Segher Boessenkool
Hi again, Thanks for your work so far! On Tue, Jun 30, 2020 at 06:53:39PM +, Christophe Leroy wrote: > On 06/30/2020 04:33 PM, Segher Boessenkool wrote: > >>>+ make -s CC=powerpc64-linux-gnu-gcc -j 160 > >>>In file included from /linux/i

Re: [PATCH v2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-06-30 Thread Segher Boessenkool
On Tue, Jun 30, 2020 at 04:55:05PM +0200, Christophe Leroy wrote: > Le 30/06/2020 à 03:19, Michael Ellerman a écrit : > >Michael Ellerman writes: > >>Because it uses the "m<>" constraint which didn't work on GCC 4.6. > >> > >>https://github.com/linuxppc/issues/issues/297 > >> > >>So we should be

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-06-12 Thread Segher Boessenkool
Hi! On Fri, Jun 12, 2020 at 02:33:09PM -0700, Nick Desaulniers wrote: > On Thu, Jun 11, 2020 at 4:53 PM Segher Boessenkool > wrote: > > The PowerPC part of > > https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints > > (sorry, no anchor) docu

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-06-11 Thread Segher Boessenkool
On Thu, Jun 11, 2020 at 03:43:55PM -0700, Nick Desaulniers wrote: > Segher, Cristophe, I suspect Clang is missing support for the %L and %U > output templates [1]. The arch/powerpc kernel first used the %U output modifier in 0c176fa80fdf (from 2016), and %L in b8b572e1015f (2008).

Re: Linux powerpc new system call instruction and ABI

2020-06-11 Thread Segher Boessenkool
Hi! On Thu, Jun 11, 2020 at 06:12:01PM +1000, Nicholas Piggin wrote: > Calling convention > -- > The proposal is for scv 0 to provide the standard Linux system call ABI > with the following differences from sc convention[1]: > > - lr is to be volatile across scv calls. This is

Re: [PATCH v10 6/6] powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH

2020-06-06 Thread Segher Boessenkool
On Sat, Jun 06, 2020 at 06:04:11PM +0530, Vaibhav Jain wrote: > >> + /* update health struct with various flags derived from health bitmap */ > >> + health = (struct nd_papr_pdsm_health) { > >> + .dimm_unarmed = p->health_bitmap & PAPR_PMEM_UNARMED_MASK, > >> +

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-05 Thread Segher Boessenkool
On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote: > On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote: > > > Third party precompiled stuff doesn't really need to concern us, since > > > none really exists. > > > > ... Yet. And if you claim

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-05 Thread Segher Boessenkool
Hi! On Fri, Jun 05, 2020 at 01:50:46PM -0400, Rich Felker wrote: > On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote: > > > I'm also not really all that convinced that vectors make a huge > > > difference in non-specialized code (autovectorization still h

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-05 Thread Segher Boessenkool
On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote: > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote: > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* > > > requires VSX - I don't think compiling for 970 introduces any actu

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
Hi! On Fri, Jun 05, 2020 at 12:26:22AM +0200, Daniel Kolesa wrote: > Either way I'll think about it some more and possibly prepare an RFC port. > I'm definitely willing to put in the work and later maintenance effort if > that's what it takes to make it happen. Yeah, you'll need to convince

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
Hi! On Thu, Jun 04, 2020 at 10:08:02PM +, Joseph Myers wrote: > > The ELFv2 document specifies things like passing of quadruple precision > > floats. Indeed, VSX is needed there, but that's not a concern if you > > *don't* use quadruple precision floats. > > My understanding is that the

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
Hi! On Thu, Jun 04, 2020 at 11:43:53PM +0200, Daniel Kolesa wrote: > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires > VSX - I don't think compiling for 970 introduces any actual differences. > There will be omissions, yes - but then the more accurate thing would be

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
Hi! On Thu, Jun 04, 2020 at 11:55:11PM +0200, Phil Blundell wrote: > 1a. Define your own subset of ELFv2 which is interworkable with the full > ABI at the function call interface but doesn't make all the same > guarantees about binary compatibility. That would mean that a binary > built with

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
Hi! On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote: > On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote: > > It is the ABI. If you think it should be different, make your own ABI, > > don't pretend the existing ABI is different than what it is. Thank

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote: > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote: > > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote: > > > well, ppc64le already cannot be run on those, as far as I know (I >

Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
On Tue, Jun 02, 2020 at 05:27:24PM +0200, Michal Suchánek wrote: > Naturally on POWER the first cpu that has LE support is POWER8 so you > can count on all other POWER8 features to be present. This is not true. The oldest CPU the ELFv2 ABI (and so, powerpc64le-linux) supports is POWER8, but most

Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Segher Boessenkool
On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote: > well, ppc64le already cannot be run on those, as far as I know (I don't think > it's possible to build ppc64le userland without VSX in any configuration) VSX is required by the ELFv2 ABI: """ Specifically, to use this ABI and

Re: [PATCH 1/4] powerpc: Add a ppc_inst_as_str() helper

2020-06-02 Thread Segher Boessenkool
to now > declare a buffer. To make it more convenient to use __ppc_inst_as_str(), > wrap it in a macro that uses a compound statement to allocate a buffer > on the caller's stack before calling it. > > Signed-off-by: Jordan Niethe Acked-by: Segher Boessenkool > +#def

Re: ppc64le and 32-bit LE userland compatibility

2020-06-02 Thread Segher Boessenkool
On Tue, Jun 02, 2020 at 01:50:32PM +, Joseph Myers wrote: > On Mon, 1 Jun 2020, Segher Boessenkool wrote: > > > > The supported glibc ABIs are listed at > > > <https://sourceware.org/glibc/wiki/ABIList>. > > > > powerpcle-linux already does work s

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Segher Boessenkool
On Tue, Jun 02, 2020 at 04:12:26AM +0200, Daniel Kolesa wrote: > On Tue, Jun 2, 2020, at 03:58, Segher Boessenkool wrote: > > I recommend new ports that cannot jump to IEEE QP float directly to use > > long double == double for the time being, avoiding the extra > > complica

Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Segher Boessenkool
On Mon, Jun 01, 2020 at 11:45:51PM +, Joseph Myers wrote: > On Tue, 2 Jun 2020, Daniel Kolesa wrote: > > Are you sure this would be a new port? Glibc already works in this > > combination, as it seems to me it'd be best if it was just a variant of > > the existing 32-bit PowerPC port,

Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Segher Boessenkool
On Tue, Jun 02, 2020 at 01:26:37AM +0200, Daniel Kolesa wrote: > On Mon, Jun 1, 2020, at 23:28, Joseph Myers wrote: > Are you sure this would be a new port? Glibc already works in this > combination, as it seems to me it'd be best if it was just a variant of the > existing 32-bit PowerPC port,

Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Segher Boessenkool
Hi Joseph, On Mon, Jun 01, 2020 at 09:28:25PM +, Joseph Myers wrote: > On Fri, 29 May 2020, Will Springer via Binutils wrote: > > > Hey all, a couple of us over in #talos-workstation on freenode have been > > working on an effort to bring up a Linux PowerPC userland that runs in > > 32-bit

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Segher Boessenkool
On Mon, Jun 01, 2020 at 12:29:56AM +0200, Daniel Kolesa wrote: > On Sun, May 31, 2020, at 22:42, Segher Boessenkool wrote: > > > There was just an assumption that LE == powerpc64le in libgo, spotted by > > > q66 (daniel@ on the CC). I just pushed the patch to [1]. > >

Re: ppc64le and 32-bit LE userland compatibility

2020-05-31 Thread Segher Boessenkool
On Sun, May 31, 2020 at 12:57:12AM +, Will Springer wrote: > On Saturday, May 30, 2020 12:22:12 PM PDT Segher Boessenkool wrote: > > The original sysv PowerPC supplement > > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf > > supports LE as well, and mos

Re: ppc64le and 32-bit LE userland compatibility

2020-05-30 Thread Segher Boessenkool
Hi! On Fri, May 29, 2020 at 07:03:48PM +, Will Springer wrote: > Hey all, a couple of us over in #talos-workstation on freenode have been > working on an effort to bring up a Linux PowerPC userland that runs in 32-bit > little-endian mode, aka ppcle. As far as we can tell, no ABI has ever

Re: [PATCH v2 6/7] powerpc/dt_cpu_ftrs: Add MMA feature

2020-05-19 Thread Segher Boessenkool
On Tue, May 19, 2020 at 10:22:40AM -0500, Paul A. Clarke wrote: > On Tue, May 19, 2020 at 10:05:56AM -0500, Segher Boessenkool wrote: > > On Tue, May 19, 2020 at 09:49:22AM -0500, Paul A. Clarke wrote: > > > On Tue, May 19, 2020 at 10:31:56AM +1000, Alistair Popple wrote: >

Re: [PATCH v2 6/7] powerpc/dt_cpu_ftrs: Add MMA feature

2020-05-19 Thread Segher Boessenkool
On Tue, May 19, 2020 at 09:49:22AM -0500, Paul A. Clarke wrote: > On Tue, May 19, 2020 at 10:31:56AM +1000, Alistair Popple wrote: > > Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and > > nit: "Matrix-Multiply Accelerator". "Matrix-Multiply Assist" in fact :-) Segher

Re: [PATCH v3] powerpc/64: Option to use ELF V2 ABI for big-endian kernels

2020-05-18 Thread Segher Boessenkool
Hi! On Mon, May 18, 2020 at 04:35:22PM +1000, Michael Ellerman wrote: > Nicholas Piggin writes: > > Provide an option to build big-endian kernels using the ELF V2 ABI. This > > works > > on GCC and clang (since about 2014). it is is not officially supported by > > the > > GNU toolchain, but it

Re: [PATCH RFC 3/4] powerpc/microwatt: Add early debug UART support for Microwatt

2020-05-11 Thread Segher Boessenkool
"r" (msr & ~MSR_DR), "r" (msr)); That should be "="(val) (an earlyclobber), because when %0 is written, %4 will still be used later. Looks fine otherwise. Reviewed-by: Segher Boessenkool Segher

Re: [PATCH] powerpc/uaccess: Don't use "m<>" constraint

2020-05-07 Thread Segher Boessenkool
a ("powerpc/uaccess: Implement unsafe_put_user() using 'asm > goto'") > Signed-off-by: Michael Ellerman Acked-by: Segher Boessenkool Thanks! So much trouble for what looked like such a simple change, all those years ago :-( Segher

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 08:10:57PM +0200, Christophe Leroy wrote: > Le 06/05/2020 à 19:58, Segher Boessenkool a écrit : > >> #define __put_user_asm_goto(x, addr, label, op) \ > >>asm volatile goto( \ > >>-

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 11:36:00AM +1000, Michael Ellerman wrote: > >> As far as I understood that's mandatory on recent gcc to get the > >> pre-update form of the instruction. With older versions "m" was doing > >> the same, but not anymore. > > > > Yes. How much that matters depends on the

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 10:58:55AM +1000, Michael Ellerman wrote: > >> The "m<>" here is breaking GCC 4.6.3, which we allegedly still support. > > > > [ You shouldn't use 4.6.3, there has been 4.6.4 since a while. And 4.6 > > is nine years old now. Most projects do not support < 4.8 anymore,

Re: [RFC PATCH 2/2] powerpc/64s: system call support for scv/rfscv instructions

2020-05-05 Thread Segher Boessenkool
Hi! On Thu, Apr 30, 2020 at 02:02:02PM +1000, Nicholas Piggin wrote: > Add support for the scv instruction on POWER9 and later CPUs. Looks good to me in general :-) > For now this implements the zeroth scv vector 'scv 0', as identical > to 'sc' system calls, with the exception that lr is not

Re: New powerpc vdso calling convention

2020-05-05 Thread Segher Boessenkool
Hi! On Wed, Apr 29, 2020 at 12:39:22PM +1000, Nicholas Piggin wrote: > Excerpts from Adhemerval Zanella's message of April 27, 2020 11:09 pm: > >> Right, I'm just talking about those comments -- it seems like the kernel > >> vdso should contain an .opd section with function descriptors in it for

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-05 Thread Segher Boessenkool
On Tue, May 05, 2020 at 05:40:21PM +0200, Christophe Leroy wrote: > >>+#define __put_user_asm_goto(x, addr, label, op)\ > >>+ asm volatile goto( \ > >>+ "1: " op "%U1%X1 %0,%1 # put_user\n" \ > >>+

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-05 Thread Segher Boessenkool
Hi! On Wed, May 06, 2020 at 12:27:58AM +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > unsafe_put_user() is designed to take benefit of 'asm goto'. > > > > Instead of using the standard __put_user() approach and branch > > based on the returned error, use 'asm goto' and make the >

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

2020-04-28 Thread Segher Boessenkool
Hi! On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote: > +config BUILD_BIG_ENDIAN_ELF_V2 > + bool "Build big-endian kernel using ELFv2 ABI (EXPERIMENTAL)" > + depends on PPC64 && CPU_BIG_ENDIAN && EXPERT > + default n > + select BUILD_ELF_V2 > + help > +

Re: [PATCH] x86: Fix early boot crash on gcc-10, next try

2020-04-25 Thread Segher Boessenkool
On Sat, Apr 25, 2020 at 08:53:13PM +0200, Borislav Petkov wrote: > On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote: > > That is a lot more typing then > > asm(""); > > That's why a macro with a hopefully more descriptive name would be > tel

Re: [PATCH] x86: Fix early boot crash on gcc-10, next try

2020-04-25 Thread Segher Boessenkool
On Sat, Apr 25, 2020 at 07:31:40PM +0200, Borislav Petkov wrote: > > There's also the one in init/main.c which is used by multiple > > architectures. On x86 at least, the call to arch_call_rest_init at the > > end of start_kernel does not get tail-call optimized by gcc-10, but I > > don't see

Re: [PATCH 1/2] powerpc: Add base support for ISA v3.1

2020-04-21 Thread Segher Boessenkool
Hi, On Tue, Apr 21, 2020 at 11:58:31AM +1000, Oliver O'Halloran wrote: > On Tue, Apr 21, 2020 at 11:53 AM Alistair Popple > wrote: > > > > On Tuesday, 21 April 2020 11:30:52 AM AEST Alistair Popple wrote: > > > On Saturday, 4 April 2020 2:32:08 AM AEST Segher Bo

Re: [PATCH 2/5] powerpc: Replace _ALIGN_DOWN() by ALIGN_DOWN()

2020-04-21 Thread Segher Boessenkool
Hi! On Tue, Apr 21, 2020 at 01:04:05AM +, Joel Stanley wrote: > On Mon, 20 Apr 2020 at 18:38, Christophe Leroy > wrote: > > _ALIGN_DOWN() is specific to powerpc > > ALIGN_DOWN() is generic and does the same > > > > Replace _ALIGN_DOWN() by ALIGN_DOWN() > > This one is a bit less obvious.

Re: How to use "y" constraint in GCC inline powerpc assembly ?

2020-04-18 Thread Segher Boessenkool
Hi! On Sat, Apr 18, 2020 at 08:28:53AM +, Christophe Leroy wrote: > I'd like to use cr instead of gpr to return error condition from > __get_user(). > > I saw in GCC doc > (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html) that it is > possible to use "y" as constraint to refer

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Segher Boessenkool
On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote: > On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote: > > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote: > > > > I think my choice would be just making the inline syscall be a sin

Re: [PATCH] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-04-16 Thread Segher Boessenkool
Hi! On Thu, Apr 16, 2020 at 07:50:00AM +0200, Christophe Leroy wrote: > Le 16/04/2020 à 00:06, Segher Boessenkool a écrit : > >On Wed, Apr 15, 2020 at 09:20:26AM +, Christophe Leroy wrote: > >>At the time being, __put_user()/__get_user() and friends only use >

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Segher Boessenkool
On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote: > > I think my choice would be just making the inline syscall be a single > > call insn to an asm source file that out-of-lines the loading of TOC > > pointer and call through it or branch based on hwcap so that it's not > > repeated

Re: [PATCH v2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-04-16 Thread Segher Boessenkool
On Thu, Apr 16, 2020 at 02:41:56PM +0200, Christophe Leroy wrote: > Le 16/04/2020 à 00:37, Segher Boessenkool a écrit : > >>+ __put_user_nocheck_goto((__typeof__(*(ptr)))(x), (ptr), > >>sizeof(*(ptr)), label) > > > >This line gets too long, can you break it

Re: [PATCH v2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-04-15 Thread Segher Boessenkool
"2: stw%U1%X1 %L0, %L1\n" \ > + EX_TABLE(1b, %l2) \ > + EX_TABLE(2b, %l2) \ > + : \ > + : "r" (x), "m" (*addr) \ > + : \ > + : label) > +#endif /* __powerpc64__ */ Here, you should drop it for sure. Rest looks fine. Reviewed-by: Segher Boessenkool Segher

Re: [PATCH] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-04-15 Thread Segher Boessenkool
ot;=r" (err) \ > - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err)) > + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err)) Here, it doesn't work. You don't want two consecutive update insns in any case. Easiest is to just not use "m<>", and then, don't use %Un (which won't do anything, but it is confusing). Same for the reads. Rest looks fine, and update should be good with that fixed as said. Reviewed-by: Segher Boessenkool Segher

Re: [PATCH v5 05/21] powerpc: Use a function for getting the instruction op code

2020-04-08 Thread Segher Boessenkool
Hi! On Mon, Apr 06, 2020 at 06:09:20PM +1000, Jordan Niethe wrote: > +static inline int ppc_inst_opcode(u32 x) > +{ > + return x >> 26; > +} Maybe you should have "primary opcode" in this function name? Segher

Re: [PATCH v5 18/21] powerpc64: Add prefixed instructions to instruction data type

2020-04-08 Thread Segher Boessenkool
On Mon, Apr 06, 2020 at 12:25:27PM +0200, Christophe Leroy wrote: > > if (ppc_inst_prefixed(x) != ppc_inst_prefixed(y)) > > return false; > > else if (ppc_inst_prefixed(x)) > > return !memcmp(, , sizeof(struct ppc_inst)); > > Are we sure memcmp() is a good

Re: [PATCH 1/2] powerpc: Add base support for ISA v3.1

2020-04-03 Thread Segher Boessenkool
Hi! On Fri, Apr 03, 2020 at 03:10:54PM +1100, Alistair Popple wrote: > +#define PCR_ARCH_300 0x10/* Architecture 3.00 */ It's called 3.0, not 3.00? Segher

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

2020-03-31 Thread Segher Boessenkool
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote: > While we are at it, can we also remove the 601 ? This one is also full > of workarounds and diverges a bit from other 6xx. > > I'm unable to find its end of life date, but it was on the market in > 1994, so I guess it must be

Re: [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start

2020-03-27 Thread Segher Boessenkool
On Fri, Mar 27, 2020 at 09:50:54AM -0700, Fangrui Song wrote: > We aim for compatibility with GNU in many aspects to make it easier for > people to switch over. However, just because there is a subtle behavior > in GNU toolchain does not mean we need to emulate that behavior. It isn't subtle. It

Re: [PATCH v2] powerpc xmon: use `dcbf` inplace of `dcbi` instruction for 64bit Book3S

2020-03-27 Thread Segher Boessenkool
On Fri, Mar 27, 2020 at 04:12:13PM +0100, Christophe Leroy wrote: > Maybe you could also change invalidate_dcache_range(): > > for (i = 0; i < size >> shift; i++, addr += bytes) { > if (IS_ENABLED(CONFIG_PPC_BOOK3S_64)) > dcbf(addr); > else

Re: [PATCH] x86: Alias memset to __builtin_memset.

2020-03-27 Thread Segher Boessenkool
Hi! On Thu, Mar 26, 2020 at 01:38:39PM +0100, Clement Courbet wrote: > --- a/arch/powerpc/include/asm/setjmp.h > +++ b/arch/powerpc/include/asm/setjmp.h > @@ -12,7 +12,9 @@ > > #define JMP_BUF_LEN23 > -extern long setjmp(long *); > -extern void longjmp(long *, long); > +typedef long *

Re: [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start

2020-03-27 Thread Segher Boessenkool
On Thu, Mar 26, 2020 at 03:26:12PM -0700, Fangrui Song wrote: > On 2020-03-26, Segher Boessenkool wrote: > >On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote: > >>.globl sets the symbol binding to STB_GLOBAL while .weak sets the > >>binding to STB_WEAK. GNU a

Re: [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start

2020-03-26 Thread Segher Boessenkool
On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote: > .globl sets the symbol binding to STB_GLOBAL while .weak sets the > binding to STB_WEAK. GNU as let .weak override .globl since binutils-gdb > 5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang integrated > assembler let the last

Re: [PATCH] powerpc/boot: Delete unneeded .globl _zimage_start

2020-03-25 Thread Segher Boessenkool
On Tue, Mar 24, 2020 at 10:18:20PM -0700, Fangrui Song wrote: > .globl sets the symbol binding to STB_GLOBAL while .weak sets the > binding to STB_WEAK. They should not be used together. It is accidetal > rather then intentional that GNU as let .weak override .globl while > clang integrated

Re: [PATCH] powerpc xmon: drop the option `i` in cacheflush

2020-03-23 Thread Segher Boessenkool
On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote: > Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit > designs prior to PowerPC architecture version 2.01 and got obsolete > from version 2.01. It was added back in 2.03. It also exists in 64-bit designs (using

Re: [PATCH] arch/powerpc/64: Avoid isync in flush_dcache_range

2020-03-20 Thread Segher Boessenkool
On Fri, Mar 20, 2020 at 08:38:42PM +0530, Aneesh Kumar K.V wrote: > On 3/20/20 8:35 PM, Segher Boessenkool wrote: > >On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote: > >>As per ISA and isync is only needed on instruction cache > >>block invalidate.

Re: [PATCH] arch/powerpc/64: Avoid isync in flush_dcache_range

2020-03-20 Thread Segher Boessenkool
On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote: > As per ISA and isync is only needed on instruction cache > block invalidate. Remove the same from dcache invalidate. Is that true on older CPUs? Segher

Re: [PATCH 12/15] powerpc/watchpoint: Prepare handler to handle more than one watcnhpoint

2020-03-18 Thread Segher Boessenkool
On Wed, Mar 18, 2020 at 12:44:52PM +0100, Christophe Leroy wrote: > Le 18/03/2020 à 12:35, Michael Ellerman a écrit : > >Christophe Leroy writes: > >>Le 09/03/2020 à 09:58, Ravi Bangoria a écrit : > >>>Currently we assume that we have only one watchpoint supported by hw. > >>>Get rid of that

Re: [PATCH 02/15] powerpc/watchpoint: Add SPRN macros for second DAWR

2020-03-18 Thread Segher Boessenkool
On Tue, Mar 17, 2020 at 11:16:34AM +0100, Christophe Leroy wrote: > > > Le 09/03/2020 à 09:57, Ravi Bangoria a écrit : > >Future Power architecture is introducing second DAWR. Add SPRN_ macros > >for the same. > > I'm not sure this is called 'macros'. For me a macro is something more >

Re: [PATCH 00/15] powerpc/watchpoint: Preparation for more than one watchpoint

2020-03-16 Thread Segher Boessenkool
On Mon, Mar 16, 2020 at 04:05:01PM +0100, Christophe Leroy wrote: > Some book3s (e300 family for instance, I think G2 as well) already have > a DABR2 in addition to DABR. The original "G2" (meaning 603 and 604) do not have DABR2. The newer "G2" (meaning e300) does have it. e500 and e600 do not

  1   2   3   4   5   6   7   8   9   10   >