On Thu, Nov 21, 2019 at 05:14:45PM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> That breaks 64-bit with GCC9:
>
> arch/powerpc/kernel/irq.c: In function 'do_IRQ':
> arch/powerpc/kernel/irq.c:650:2: error: PIC register clobbered by 'r2' in
> 'asm'
> 650 | asm volatile(
>
On Tue, Nov 05, 2019 at 07:04:04AM +0100, Christophe Leroy wrote:
> Le 04/11/2019 à 20:43, Segher Boessenkool a écrit :
> >Please send this separately, to be committed right now? It is a bug fix,
> >independent of the rest of the series.
>
> Patch 4/6 needs it, as
On Mon, Nov 04, 2019 at 01:32:53PM +1100, Alastair D'Silva wrote:
> When calling flush_icache_range with a size >4GB, we were masking
> off the upper 32 bits, so we would incorrectly flush a range smaller
> than intended.
>
> This patch replaces the 32 bit shifts with 64 bit ones, so that
> the
On Wed, Oct 30, 2019 at 10:55:03PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> >> Some of our scripts are passed $objdump and then call it as
> >> "$objdump". This doesn
On Tue, Oct 29, 2019 at 02:15:39PM -0700, Kees Cook wrote:
> On Tue, Oct 15, 2019 at 06:54:13PM +0200, Borislav Petkov wrote:
> > On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
> > > Names *matter*, internal names doubly so. So why replace a good name with
On Sun, Oct 27, 2019 at 10:21:25AM +0100, Christophe Leroy wrote:
> Le 27/10/2019 à 01:06, Segher Boessenkool a écrit :
> >The hand-optimised asm code will pretty likely win handsomely, whatever
> >you do. Especially on cores like the 885 (no branch prediction, single
> >iss
On Sat, Oct 26, 2019 at 08:48:27PM +0200, Thomas Gleixner wrote:
> On Sat, 26 Oct 2019, Christophe Leroy wrote:
> Let's look at the code:
>
> __cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
> {
> const struct vdso_data *vd = __arch_get_vdso_data();
>
>
On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> >> When booting under OF the zImage expects the initrd address an
On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> Some of our scripts are passed $objdump and then call it as
> "$objdump". This doesn't work if it contains spaces because we're
> using ccache, for example you get errors such as:
>
> ./arch/powerpc/tools/relocs_check.sh: line
On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> When booting under OF the zImage expects the initrd address and size to be
> passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU)
> currently doesn't do this so the zImage is not aware of the initrd
>
On Mon, Oct 21, 2019 at 10:15:29PM -0700, Nathan Chancellor wrote:
> On Fri, Oct 18, 2019 at 03:02:10PM -0500, Segher Boessenkool wrote:
> > I think the proper solution is for the kernel to *do* use -ffreestanding,
> > and then somehow tell the kernel that memcpy etc. a
On Fri, Oct 18, 2019 at 12:00:22PM -0700, Nathan Chancellor wrote:
> Just as an FYI, there was some more discussion around the availablity
> and use of bcmp in this LLVM bug which spawned
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp").
>
>
On Mon, Oct 14, 2019 at 08:56:12AM -0700, Nick Desaulniers wrote:
> On Mon, Oct 14, 2019 at 2:35 AM Segher Boessenkool
> wrote:
> >
> > On Sun, Oct 13, 2019 at 07:51:01PM -0700, Nathan Chancellor wrote:
> > > r374662 gives LLVM the ability to convert certain loops int
On Sun, Oct 13, 2019 at 07:51:01PM -0700, Nathan Chancellor wrote:
> r374662 gives LLVM the ability to convert certain loops into a reference
> to bcmp as an optimization; this breaks prom_init_check.sh:
When/why does LLVM think this is okay? This function has been removed
from POSIX over a
On Fri, Oct 11, 2019 at 09:11:43AM -0700, Kees Cook wrote:
> On Fri, Oct 11, 2019 at 03:25:19AM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
> > > The Program Header identifiers are internal to the linker scripts. In
> >
On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
> The Program Header identifiers are internal to the linker scripts. In
> preparation for moving the NOTES segment declaration into RO_DATA,
> standardize the identifier for the PT_NOTE entry to "note" as used by
> all other architectures
On Thu, Sep 19, 2019 at 07:23:18AM +0200, Christophe Leroy wrote:
> Le 18/09/2019 à 18:39, Segher Boessenkool a écrit :
> >I realise the original code had this... Loading the old stack pointer
> >value back from the stack creates a bottleneck (via the store->load
> &g
able.
I don't know if using functions as an "i" works properly... It probably
does, it's just not something that you see often :-)
What about r2? Various ABIs handle that differently. This might make
it impossible to share implementation between 32-bit and 64-bit for this.
But we could add it to the clobber list worst case, that will always work.
So anyway, it looks to me like it will work. Nice cleanup. Would be
better if you could do the call to __do_irq from C code, but maybe we
cannot have everything ;-)
Reviewed-by: Segher Boessenkool
Segher
On Tue, Sep 10, 2019 at 02:55:27PM +, Christophe Leroy wrote:
> arch/powerpc/kernel/ contains 7 files dedicated to kexec.
>
> Move them into a dedicated subdirectory.
> arch/powerpc/kernel/{ => kexec}/ima_kexec.c| 0
> arch/powerpc/kernel/{ => kexec}/kexec_32.S | 2 +-
>
erated
code a little shorter.
Signed-off-by: Segher Boessenkool
[1] See
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-returns_005ftwice-function-attribute
---
arch/powerpc/include/asm/setjmp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
On Wed, Sep 04, 2019 at 01:23:36PM +1000, Alastair D'Silva wrote:
> > Maybe also add "msr" in the clobbers.
> >
> Ok.
There is no known register "msr" in GCC.
Segher
On Wed, Sep 04, 2019 at 08:16:45AM +, David Laight wrote:
> From: Nathan Chancellor [mailto:natechancel...@gmail.com]
> > Fair enough so I guess we are back to just outright disabling the
> > warning.
>
> Just disabling the warning won't stop the compiler generating code
> that breaks a
On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote:
> On Thu, Aug 29, 2019 at 09:59:48AM +, David Laight wrote:
> > From: Nathan Chancellor
> > > Sent: 28 August 2019 19:45
> > ...
> > > However, I think that -fno-builtin-* would be appropriate here because
> > > we are
On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> >(Why are they separate though? It could just be one loop var).
>
> Yes it could just be a single loop var, but in that case it would have
> to be
On Tue, Sep 03, 2019 at 04:28:09PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
> >On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> >>+ asm volatile(
> >>+ " mtctr %2;"
> >>+
Hi!
On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> +#if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64)
Please write that as &&? That is more usual, and thus, easier to read.
> +static void
On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:
> Michal Suchanek writes:
> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> > less so on littleendian.
>
> I think the toolchain people will tell you that there is no 32-bit
> little endian ABI defined
On Mon, Sep 02, 2019 at 11:48:59AM +1000, Michael Ellerman wrote:
> "Alastair D'Silva" writes:
> > On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:
> >> Can we be 100% sure that GCC won't add any code accessing some
> >> global data or stack while the Data MMU is OFF ?
> >
> > +mpe
> >
On Thu, Aug 29, 2019 at 07:38:01PM +1000, Nicholas Piggin wrote:
> So... this actually seems to work. Haven't booted it, but the compiler
> seems to do what we want.
>From the GCC manual:
After defining a global register variable, for the current compilation
unit:
* If the register is
On Wed, Aug 28, 2019 at 03:16:19PM -0700, Nick Desaulniers wrote:
> That's a good reason IMO. IIRC, the -fno-builtin-* flags don't warn
> if * is some unrecognized value, so -fno-builtin-setjmp may not
> actually do anything, and you may need to scan the source (of clang or
> llvm).
On Tue, Aug 27, 2019 at 08:33:45PM +0200, Christophe Leroy wrote:
> >So
> > asm("add%I2 %0,%1,%2" : "=r"(dst) : "r"(src1), "ri"(src1));
>
> "ri", not "n" as for wrtee ?
"n" means a number. "i" means any constant integer. The difference is
mostly that "n" does not allow relocations. This
On Tue, Aug 27, 2019 at 07:36:35PM +0200, Christophe Leroy wrote:
> Le 27/08/2019 à 19:29, Segher Boessenkool a écrit :
> >On Tue, Aug 27, 2019 at 10:48:24PM +1000, Nicholas Piggin wrote:
> >>Christophe Leroy's on August 27, 2019 6:13 pm:
> >>>+#define wrtee(val)
On Tue, Aug 27, 2019 at 10:48:24PM +1000, Nicholas Piggin wrote:
> Christophe Leroy's on August 27, 2019 6:13 pm:
> > +#define wrtee(val) asm volatile("wrtee %0" : : "r" (val) : "memory")
> > +#define wrteei(val)asm volatile("wrteei %0" : : "i" (val) :
> > "memory")
>
> Can you implement
On Tue, Aug 27, 2019 at 01:30:09PM +1000, Nicholas Piggin wrote:
> -435 nospu clone3 ppc_clone3
> +435 32 clone3 ppc_clone3
> sys_clone3
> +435 64 clone3 sys_clone3
> +435 nospu
On Mon, Aug 26, 2019 at 09:41:39PM +1000, Michael Ellerman wrote:
> Given how many 601 users there are, maybe 1?, I think that would be a
> simpler option and avoids complicating the code / binary for everyone
> else.
Or you could remove 601 support altogether?
Segher
On Wed, Aug 21, 2019 at 01:50:52PM +0200, Christophe Leroy wrote:
> Le 21/08/2019 à 13:44, Segher Boessenkool a écrit :
> >Calls are cheap, in principle... It is the LR stuff that can make it
> >slower on some cores, and a lot of calling sequence stuff may have
> >considerab
Hi!
On Wed, Aug 21, 2019 at 02:59:59PM +0530, Santosh Sivaraj wrote:
> except for a couple of calls (1 or 2 nsec reduction), there are no
> improvements in the call times. Or is 10 nsec the minimum granularity??
>
> So I don't know if its even worth updating vdso64 except to keep vdso32 and
>
On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote:
> On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote:
> > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> > > When building pseries_defconfig, building vdso32 errors out:
&g
On Mon, Aug 19, 2019 at 05:05:46PM +0200, Christophe Leroy wrote:
> Le 19/08/2019 à 16:37, Segher Boessenkool a écrit :
> >On Mon, Aug 19, 2019 at 04:08:43PM +0200, Christophe Leroy wrote:
> >>Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :
> >>>On Mon, Au
On Mon, Aug 19, 2019 at 04:08:43PM +0200, Christophe Leroy wrote:
> Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :
> >On Mon, Aug 19, 2019 at 01:06:31PM +, Christophe Leroy wrote:
> >>Note that we keep using an assembly text using "twi 31, 0, 0" for
> &g
On Mon, Aug 19, 2019 at 01:58:12PM +, Christophe Leroy wrote:
> -#define LOAD_REG_IMMEDIATE_SYM(reg,expr) \
> - lis reg,(expr)@highest; \
> - ori reg,reg,(expr)@higher; \
> - rldicr reg,reg,32,31; \
> - orisreg,reg,(expr)@__AS_ATHIGH;
Hi Christophe,
On Mon, Aug 19, 2019 at 01:58:10PM +, Christophe Leroy wrote:
> +.macro __LOAD_REG_IMMEDIATE r, x
> + .if (\x) >= 0x8000 || (\x) < -0x8000
> + __LOAD_REG_IMMEDIATE_32 \r, (\x) >> 32
> + sldi\r, \r, 32
> + .if (\x) & 0x
On Mon, Aug 19, 2019 at 01:06:31PM +, Christophe Leroy wrote:
> Note that we keep using an assembly text using "twi 31, 0, 0" for
> inconditional traps because GCC drops all code after
> __builtin_trap() when the condition is always true at build time.
As I said, it can also do this for
On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> When building pseries_defconfig, building vdso32 errors out:
>
> error: unknown target ABI 'elfv1'
>
> Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
> powerpc64le toolchain") added these flags to fix
On Mon, Aug 19, 2019 at 07:40:42AM +0200, Christophe Leroy wrote:
> Le 18/08/2019 à 14:01, Segher Boessenkool a écrit :
> >On Sat, Aug 17, 2019 at 09:04:42AM +, Christophe Leroy wrote:
> >>Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger
> >>of the t(d/w)nei i
Hi Christophe,
On Sat, Aug 17, 2019 at 06:37:50PM +, Christophe Leroy wrote:
> #define BUG() do { \
> + __builtin_trap(); \
GCC will optimise away all code after this, it knows it is unreachable.
But you
On Sat, Aug 17, 2019 at 09:04:42AM +, Christophe Leroy wrote:
> Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger
> of the t(d/w)nei instruction instead of using directly the
> value of x.
>
> This leads to GCC adding unnecessary pair of addic/subfe.
And it has to, it is passed as an
On Fri, Aug 16, 2019 at 01:01:50PM +, Christophe Leroy wrote:
> - add r3,r3,r5
> +78: add r3,r3,r5
You can use actual names for the labels as well... .Lsomething if you
want it to stay a local symbol only.
Segher
Hi Christophe,
On Tue, Aug 13, 2019 at 09:59:35AM +, Christophe Leroy wrote:
> + rldicr \r, \r, 32, 31
Could you please write this as
sldi\r, \r, 32
? It's much easier to read, imo (it's the exact same instruction).
You can do a lot cheaper sequences if you
On Wed, Aug 14, 2019 at 08:46:15PM +1000, Michael Ellerman wrote:
> Claudio Carvalho writes:
> > +_GLOBAL(ucall_norets)
> > +EXPORT_SYMBOL_GPL(ucall_norets)
> > + mfcrr0
> > + stw r0,8(r1)
> > +
> > + sc 2 /* Invoke the ultravisor */
> > +
> > + lwz r0,8(r1)
On Fri, Aug 09, 2019 at 10:12:56PM +0200, Arnd Bergmann wrote:
> @@ -106,7 +106,7 @@ static inline u##size name(const volatile u##size
> __iomem *addr)\
> { \
> u##size ret;
On Fri, Aug 09, 2019 at 10:03:01PM +0200, Christophe Leroy wrote:
> Arnd Bergmann a écrit :
>
> >On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> >Linux wrote:
> >
> >> static inline void dcbz(void *addr)
> >> {
> >>- __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8
On Fri, Aug 09, 2019 at 08:28:19PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
>
> > static inline void dcbz(void *addr)
> > {
> > - __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr) : "memory");
> > + __asm__
On Tue, Aug 06, 2019 at 10:14:27PM +1000, Michael Ellerman wrote:
> Christopher M Riedl writes:
> > Yep, and that's no good. Hmm, executing the barrier() in the
> > non-shared-processor
> > case probably hurts performance here?
>
> It's only a "compiler barrier", so it shouldn't generate any
On Thu, Aug 01, 2019 at 10:26:28PM +1000, Michael Ellerman wrote:
> GCC 9 fails to build some of the ptrace TM tests, with errors such as:
>
> ptrace-tm-spd-vsx.c: In function 'tm_spd_vsx':
> ptrace-tm-spd-vsx.c:51:2: error: listing the stack pointer register 'r1' in
> a clobber list is
On Tue, Jul 30, 2019 at 08:24:14PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 6:16 PM Segher Boessenkool
> wrote:
> > in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> > well, its (not byte reversing) read will be atomic just fine, so things
&
On Tue, Jul 30, 2019 at 11:16:37AM -0500, Segher Boessenkool wrote:
> in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> well, its (not byte reversing) read will be atomic just fine, so things
> will still work correctly.
>
> The things defined with DEF_MMI
On Tue, Jul 30, 2019 at 04:30:29PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> > > Upon a second look, I think the issue is that the "Z" is a
On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> Upon a second look, I think the issue is that the "Z" is an input argument
> when it should be an output. clang decides that it can make a copy of the
> input and pass that into the inline asm. This is not the most efficient
> way,
On Mon, Jul 29, 2019 at 01:32:46PM -0700, Nathan Chancellor wrote:
> For the record:
>
> https://godbolt.org/z/z57VU7
>
> This seems consistent with what Michael found so I don't think a revert
> is entirely unreasonable.
Try this:
https://godbolt.org/z/6_ZfVi
This matters in non-trivial
On Tue, Jul 23, 2019 at 09:21:53AM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> >> can use both RA and RB to compute the address, rather than us forcing RA
> >> to 0.
> >>
> >> But at least with my compiler here (GCC 8 vintage) I don't act
On Mon, Jul 22, 2019 at 10:21:07AM -0700, Nick Desaulniers wrote:
> On Sun, Jul 21, 2019 at 11:19 PM Segher Boessenkool
> wrote:
> > On Sun, Jul 21, 2019 at 07:41:40PM -0700, Nathan Chancellor wrote:
> > > On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
&
On Mon, Jul 22, 2019 at 08:15:14PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> >> 017c clear_user_page:
> >> 17c: 94 21 ff f0 stwu 1, -16(1)
On Sun, Jul 21, 2019 at 07:41:40PM -0700, Nathan Chancellor wrote:
> Hi Segher,
>
> On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> > > 017c clear_user_page:
>
On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> I have attached the disassembly of arch/powerpc/kernel/mem.o with
> clear_page (working) and broken_clear_page (broken), along with the side
> by side diff. My assembly knowledge is fairly limited as it stands and
> it is
On Thu, Jul 18, 2019 at 08:24:56PM -0700, Nathan Chancellor wrote:
> On Mon, Jul 08, 2019 at 11:49:52PM -0700, Nathan Chancellor wrote:
> > On Tue, Jul 09, 2019 at 07:04:43AM +0200, Christophe Leroy wrote:
> > > Is that a Clang bug ?
> >
> > No idea, it happens with clang-8 and clang-9 though
Hi!
On Thu, Jul 18, 2019 at 11:19:58AM +0900, Masahiro Yamada wrote:
> On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool
> wrote:
> Kbuild always uses thin archives as far as vmlinux is concerned.
>
> But, there are some other call-sites.
>
> masahiro@pug:~/ref/l
(Sorry to hijack your reply).
On Thu, Jul 18, 2019 at 06:11:48PM +1000, Alexey Kardashevskiy wrote:
> On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
> >From: Ram Pai
> >+static int enter_secure_mode(unsigned long kbase, unsigned long fdt)
> >+{
> >+register uint64_t func asm("r3") =
On Thu, Jul 18, 2019 at 12:19:36AM +0900, Masahiro Yamada wrote:
> On Wed, Jul 17, 2019 at 11:38 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > And it's def
On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> And it's definitely calling ar with no flags, eg:
>
> rm -f init/built-in.a; powerpc-linux-ar rcSTPD init/built-in.a init/main.o
> init/version.o init/do_mounts.o init/do_m
On Mon, Jul 15, 2019 at 09:03:46PM +0900, Masahiro Yamada wrote:
> On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool
> wrote:
> >
> > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > > Yes, that is w
On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > Yes, that is why I used the environment variable, all binutils work
> > with that. There was no --target option in GNU ar before 2.22.
>
> Yeah, we're not very good at te
On Sun, Jul 14, 2019 at 07:45:15AM +0900, Masahiro Yamada wrote:
> On Sat, Jul 13, 2019 at 10:17 PM Segher Boessenkool
> wrote:
> > On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> > > On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
>
On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> > The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> > in a useful way because it is always overridden by the following code
On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> in a useful way because it is always overridden by the following code
> in the top Makefile:
>
> # use the deterministic mode of AR if available
>
On Tue, Jul 09, 2019 at 08:21:54AM +0530, Aneesh Kumar K.V wrote:
> On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
> >I don't think it's that, there's some magic in flush_icache_range() to
> >handle dropping prefetched instructions on 970.
> >
> >>So overall wondering why we need that extra barriers
instructions (dcbz, dcbi, dcbf and dcbst) take two registers
> >>>that are summed to obtain the target address. Using 'Z' constraint
> >>>and '%y0' argument gives GCC the opportunity to use both registers
> >>>instead of only one with the second being forced
On Tue, Jul 02, 2019 at 11:16:35AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 03, 2019 at 01:19:34AM +1000, Michael Ellerman wrote:
> > What we could do is switch to the `UL` macro from include/linux/const.h,
> > rather than using our own ASM_CONST.
>
> You n
On Wed, Jul 03, 2019 at 01:19:34AM +1000, Michael Ellerman wrote:
> What we could do is switch to the `UL` macro from include/linux/const.h,
> rather than using our own ASM_CONST.
You need gas 2.28 or later for that though.
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=86b80085
On Sun, Jun 23, 2019 at 08:41:51PM +1000, Nicholas Piggin wrote:
> This makes it clear to the caller that it can only be used on POWER9
> and later CPUs.
> -#define PPC_INVALIDATE_ERAT PPC_SLBIA(7)
> +#define PPC_ARCH_300_INVALIDATE_ERAT PPC_SLBIA(7)
The architecture version is 3.0 (or 3.0B),
This is because output 'res' must be marked as an earlyclobber operand so
> it may not overlap an input operand ('vecoutptr').
>
> Signed-off-by: Gustavo Romero
Reviewed-by: Segher Boessenkool
Segher
> ---
> tools/testing/selftests/powerpc/tm/tm-vmxcopy.c | 2 +-
>
Hi Paul,
On Mon, Jun 17, 2019 at 12:06:32PM +1000, Paul Mackerras wrote:
> The thing we need to consider is that when SMFCTRL[E] = 0, a ucall
> instruction becomes a hcall (that is, sc 2 is executed as if it was
> sc 1). In that case, the first argument to the ucall will be
> interpreted as the
On Mon, Jun 17, 2019 at 06:53:47PM +0200, Andreas Schwab wrote:
> AS arch/powerpc/kernel/swsusp_32.o
> arch/powerpc/kernel/swsusp_32.S: Assembler messages:
> arch/powerpc/kernel/swsusp_32.S:109: Error: invalid bat number
> arch/powerpc/kernel/swsusp_32.S:111: Error: invalid bat number
On Tue, Jun 04, 2019 at 07:18:42AM +1000, Benjamin Herrenschmidt wrote:
> Yes we could make property fetching faster but mostly by creating a new
> bulk interface which is quite a bit of work, a new API, and will in
> practice not be used for anything other than creating the FDT. In that
> case,
Hi!
On Mon, Jun 03, 2019 at 12:56:26PM +1000, Alexey Kardashevskiy wrote:
> On 03/06/2019 09:23, Segher Boessenkool wrote:
> >> So I go for the simple one and agree with Alexey's idea.
> >
> > When dealing with a whole device tree you have to know about the various
&
Hi!
On Fri, May 31, 2019 at 11:03:26AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-05-30 at 14:37 -0500, Segher Boessenkool wrote:
> > On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> > > so, it is sort-of nack from David and sort-of ack
On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> so, it is sort-of nack from David and sort-of ack from Segher, what
> happens now?
Maybe what we really need just a CI call to get all properties of a node
at once? Will that speed up things enough?
That way you need no
On Tue, May 14, 2019 at 09:49:18AM -0300, Shawn Landden wrote:
> ARM does this, so we might as well too.
> I am a bit confused however as CONFIG_ALTIVEC does not select
> CONFIG_PPC_FPU. Would you ever have altivec without a fpu?
There is no hardware like that, none supported anyway. It does not
On Tue, May 07, 2019 at 06:53:30PM +0200, Christophe Leroy wrote:
> Le 07/05/2019 à 17:10, Segher Boessenkool a écrit :
> >On Tue, May 07, 2019 at 01:31:39PM +, Christophe Leroy wrote:
> >>Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
> >&g
On Tue, May 07, 2019 at 07:43:56PM +0530, Mahesh J Salgaonkar wrote:
> Can we use SPRN_* #defines which are already present in asm/reg.h instead of
> hard coding numbers for switch cases ? You may want to add new #defines
> for NIP, MSR and CCR.
But none of those three are SPRs. Please don't
Hi Christophe,
On Tue, May 07, 2019 at 01:31:39PM +, Christophe Leroy wrote:
> Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
> that are summed to obtain the target address. Using '%y0' argument
> gives GCC the opportunity to use both registers instead of only one
> with
Hi!
On Mon, May 06, 2019 at 04:31:38PM +, Christophe Leroy wrote:
> However, I've tried your suggestion below and get unnexpected result.
> >you can do
> >
> > __asm__ __volatile__ ("dcbf %0" : : "Z"(addr) : "memory");
> >
> >to save some insns here and there. ]
This should be "dcbf
On Mon, May 06, 2019 at 09:34:55AM +0200, Rasmus Villemoes wrote:
> I _am_ bending the C rules a bit with the "extern some_var; asm
> volatile(".section some_section\nsome_var: blabla");". I should probably
> ask on the gcc list whether this way of defining a local symbol in
> inline assembly and
Hi Christophe,
On Fri, May 03, 2019 at 04:14:13PM +0200, Christophe Leroy wrote:
> A while ago I proposed the following patch, and didn't get any comment
> back on it.
I didn't see it. Maybe because of holiday :-)
> Do you have any opinion on it ? Is it good and worth it ?
> Le 09/01/2018 à
On Fri, May 03, 2019 at 10:10:57AM +1000, Stewart Smith wrote:
> David Gibson writes:
> > On Wed, May 01, 2019 at 01:42:21PM +1000, Alexey Kardashevskiy wrote:
> >> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> >> about 8.5sec to fetch the entire device tree via the
On Wed, May 01, 2019 at 01:42:21PM +1000, Alexey Kardashevskiy wrote:
> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> about 8.5sec to fetch the entire device tree via the client interface
> as the DT is traversed twice - for strings blob and for struct blob.
> Also,
Acked-by: Segher Boessenkool
(But see comments below.)
On Mon, Apr 29, 2019 at 09:08:09AM +, Christophe Leroy wrote:
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index bf1de3ca39bc..37cf2af98f6a 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/
On Mon, Apr 29, 2019 at 10:43:27AM +, Christophe Leroy wrote:
> To increase readability/maintainability, replace hard coded
> instructions values by symbolic names.
> + /* lis r12,sym@ha */
> +#define ENTRY_JMP0(sym) (PPC_INST_ADDIS | __PPC_RT(R12) | PPC_HA(sym))
> + /* addi
On Mon, Apr 29, 2019 at 06:52:41AM -0500, Christoph Hellwig wrote:
> This export was added in this merge window, but without any actual
> user, or justification for a modular user.
Hi Christoph,
> -unsigned long __kernel_io_end;
> EXPORT_SYMBOL(__kernel_io_end);
Does that work? Don't you need
On Fri, Apr 26, 2019 at 05:38:50PM +0300, Serge Belyshev wrote:
> ---[ Instruction Block Address Translation ]---
> 0: 0xc000-0xc07f 0x Kernel EXEC coherent
> 1: 0xc080-0xc087 0x0080 Kernel EXEC coherent
> 2: -
> 3: -
> 4: -
> 5: -
> 6:
501 - 600 of 1471 matches
Mail list logo
