On Mon, Nov 05, 2018 at 02:48:49PM +1100, Michael Ellerman wrote:
> Joel Stanley writes:
> > When building for ppc32 with clang these flags are unsupported:
> >
> > -ffixed-r2 and -mmultiple
> > -CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
> > +ifndef CONFIG_CC_IS_CLANG
> >
On Fri, Nov 02, 2018 at 10:38:36AM -0700, Nick Desaulniers wrote:
> On Fri, Nov 2, 2018 at 10:34 AM Segher Boessenkool
> wrote:
> >
> > On Fri, Nov 02, 2018 at 02:07:13PM +1030, Joel Stanley wrote:
> > > arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a c
Hi!
On Mon, Oct 01, 2018 at 12:22:56PM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 09:11:04 +0800
> Bin Meng wrote:
> > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin wrote:
> > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > Bin Meng wrote:
> > > > commit 573ebfa6601f ("powerpc: Increase
On Sat, Sep 29, 2018 at 11:25:19PM -0700, Bin Meng wrote:
> The -mabi=elfv2 is currently specified twice in the makefile. Remove
> the one that does not test compiler.
This was
ifdef CONFIG_PPC64
cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
On Sat, Sep 29, 2018 at 11:25:20PM -0700, Bin Meng wrote:
> /*
> - * Size of redzone that userspace is allowed to use below the stack
> + * Size of redzone that kernel/userspace is allowed to use below the stack
> * pointer. This is 288 in the 64-bit big-endian ELF ABI, and 512 in
> * the
Hi Raz,
On Sun, Sep 30, 2018 at 12:24:35AM +0300, Raz wrote:
> I want to learn about powerpc architecture, mainly hypervisor and
> partioning. I download the books (1,2, and 3 ) but I feel it lacks
> a lot of information. Are there other books ?
I suspect you are looking at an ancient version
On Thu, Oct 11, 2018 at 08:22:54AM +1030, Joel Stanley wrote:
> On Wed, 10 Oct 2018 at 22:41, Michael Ellerman wrote:
> > Joel Stanley writes:
> > > BOOTCFLAGS:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> > > - -fno-strict-aliasing -Os -msoft-float -pipe \
> > > -
On Tue, Oct 02, 2018 at 09:59:29AM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 03:51:21 -0500
> Segher Boessenkool wrote:
> > And that is required by the ABI!
> >
> > """
> > 2.2.2.4. Protected Zone
> >
> > The 288 bytes
On Thu, Oct 04, 2018 at 10:41:13AM +0300, Raz wrote:
> Frankly, the more I read the more perplexed I get. For example,
> according to BOOK III-S, chapter 3,
> the MSR bits are differ from the ones described in
> arch/powerpc/include/asm/reg.h.
> Bit zero, is LE, but in the book it is 64-bit mode.
On Sat, Oct 06, 2018 at 12:19:45PM +0300, Raz wrote:
> Hey
> How does HVSC works ?
> I looked in the code and LoPAR documentation. It looks like there is
> vector called
> system_call_pSeries ( at 0xc00 ) that is supposed to be called when we
> invoke HVSC from kernel
> mode.
> Now, I wrote a NULL
On Mon, Oct 08, 2018 at 07:44:12PM +0300, Raz wrote:
> Both systemsim and my powerpc server boots with MSR_HV=1, i.e, hypervisor
> state.
> Is there away to fix that ? writing to the MSR cannot work according
> the documentation ( and reality ).
But that is what you do: you write HV=0 in MSR.
On Sun, Sep 30, 2018 at 10:05:01AM +0300, Raz wrote:
> First, thank you.
> And another question, is there a development environment that
> resembles Fixed Virtual Platform for ARM ( FVP ARM) ?
I don't know FVP, but that seems similar to systemsim?
On Wed, Sep 19, 2018 at 04:22:52PM +0200, Christophe LEROY wrote:
> >It looks like it will be easy to enable on 64 bit as well.
>
> Will it ? It seems that PPC64 doesn't have r2 pointing to current task
> struct, but instead it has r13 pointing to the paca struct. Which means
> we should add a
On Wed, Sep 26, 2018 at 11:41:26AM +0200, Christophe LEROY wrote:
> Le 26/09/2018 à 11:28, Segher Boessenkool a écrit :
> >On Wed, Sep 26, 2018 at 09:58:30AM +0200, Christophe LEROY wrote:
> >>Segher, any idea about this problem ?
> >
> >>>>arch/powerpc/platf
On Wed, Sep 26, 2018 at 11:40:38AM +, Christophe Leroy wrote:
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(, sizeof(canary));
> + canary ^= mftb();
> +
On Wed, Sep 26, 2018 at 09:58:30AM +0200, Christophe LEROY wrote:
> Segher, any idea about this problem ?
> >>arch/powerpc/platforms/powermac/bootx_init.o: In function `bootx_printf':
> >>/var/lib/jenkins-slave/workspace/snowpatch/snowpatch-linux-
>
On Wed, Sep 19, 2018 at 11:14:45AM +, Christophe Leroy wrote:
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -112,6 +112,10 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
> KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
> endif
>
>
On Thu, Sep 20, 2018 at 03:29:22PM +0530, Madhavan Srinivasan wrote:
> On Thursday 20 September 2018 03:11 PM, Michael Ellerman wrote:
> >In power7_marked_instr_event() there is a switch case that is missing
> >a break or an explicit fallthrough, it's not immediately clear which
> >it should be.
Hi!
On Mon, Sep 17, 2018 at 12:15:05PM +, Christophe Leroy wrote:
> Now, GCC offers the possibility to manually set the
> stack-protector mode (global or tls) regardless of libc support.
Yup :-)
> This time, the patch selects HAVE_STACKPROTECTOR only if
> -mstack-protector-guard=global is
On Thu, Sep 27, 2018 at 08:20:00AM +0200, Christophe LEROY wrote:
> Le 26/09/2018 à 21:16, Segher Boessenkool a écrit :
> >On Wed, Sep 26, 2018 at 11:40:38AM +, Christophe Leroy wrote:
> >>+static __always_inline void boot_init_stack_canary(void)
> >>+{
&
On Fri, Sep 28, 2018 at 10:56:07PM +1000, Michael Ellerman wrote:
> The problem of low entropy at boot on systems without a good hardware
> source is sort of unsolvable.
>
> As you say it's up to the core kernel/random code, we shouldn't be
> trying to do anything tricky in the arch code.
>
>
On Thu, Dec 27, 2018 at 02:32:07AM +, Ben Hutchings wrote:
> On Wed, 2018-12-26 at 17:45 -0600, Segher Boessenkool wrote:
> > Hi!
> >
> > On Wed, Dec 26, 2018 at 02:15:11PM +, Ben Hutchings wrote:
> > > GCC for Debian's "powerpcspe" architectur
On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote:
> The recent rewrite of the SLB code into C included the assumption that
> all CPUs we run on have at least 32 SLB entries. This is currently
> true but a bit fragile as the SLB size is actually defined by the
> device tree and so
On Fri, Jan 18, 2019 at 11:28:24PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
>
> > On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote:
> >> The recent rewrite of the SLB code into C included the assumption that
> >> all CPUs we run o
On Sun, Jan 13, 2019 at 11:33:56PM +1100, Balbir Singh wrote:
> On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > > Could you please define interesting frame on top a bit more? Usually
> &
On Sat, Dec 22, 2018 at 02:08:02PM +0100, christophe leroy wrote:
>
> Usually, Guarded implies no exec (at least on 6xx and 8xx).
Huh? What do you mean here?
Segher
On Sun, Dec 23, 2018 at 09:29:44AM +0100, Gabriel Paubert wrote:
> • The fetch access is to guarded storage and MSR[IR] = 1.
That is architected, yes. You get an ISI if IR=1 and (N=1 or G=1).
Segher
Hi!
On Wed, Dec 26, 2018 at 02:15:11PM +, Ben Hutchings wrote:
> GCC for Debian's "powerpcspe" architecture only supports 32-bit
> SPE targets, and using -mcpu=powerpc or -mcpu=powerpc64 is a fatal
> error.
I don't see where your patch touches -mcpu=powerpc, and I don't see how
it would make
On Sat, Dec 22, 2018 at 08:37:28PM +0100, christophe leroy wrote:
> Le 22/12/2018 à 18:16, Segher Boessenkool a écrit :
> >On Sat, Dec 22, 2018 at 02:08:02PM +0100, christophe leroy wrote:
> >>
> >>Usually, Guarded implies no exec (at least on 6xx and 8xx).
> &g
On Tue, Dec 04, 2018 at 11:24:28AM +1030, Joel Stanley wrote:
> Alan Modra explains:
>
> > Likely you could discard .interp > and .dynstr too, and .dynsym when
> > !CONFIG_PPC32.
>
> Discarding of interp and dynstr happened in a previous patch. The dynsym
> cleanup was a bit less
On Tue, Dec 04, 2018 at 08:43:47AM +1030, Joel Stanley wrote:
> On Tue, 4 Dec 2018 at 05:15, Nick Desaulniers wrote:
> > > > > +ifdef CONFIG_CC_IS_CLANG
> > > > > +# clang ppc port does not yet support -maltivec when -msoft-float is
> > > > > +# enabled. A future release of clang will resolve
make future syncs
> obvious. Other parts of sfp-machine.h were left as-is as the file
> contains more features than present in longlong.h.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/260
> Signed-off-by: Joel Stanley
This looks fine, thanks!
Reviewed-by: Segher Boessenkool
Segher
On Tue, Nov 20, 2018 at 10:45:19AM -0800, Nick Desaulniers wrote:
> On Tue, Nov 20, 2018 at 10:20 AM Segher Boessenkool
> wrote:
> > > Segher, which tree contains the One True Upstream for longlong.h?
> >
> > You should probably get your updates from the same place as w
On Tue, Nov 20, 2018 at 09:45:33AM +1030, Joel Stanley wrote:
> On Tue, 20 Nov 2018 at 05:24, Nick Desaulniers
> wrote:
> > >
> > > The only functional change I noticed was this in udiv_qrnnd.
> > >
> > > __r1 = (n1) % __d1;
> > > __q1 = (n1) / __d1;
> > >
> > > Becomes this:
> > >
> > >
On Thu, Jan 10, 2019 at 08:10:43AM +0100, Christophe Leroy wrote:
> Le 10/01/2019 à 02:42, Joel Stanley a écrit :
> >From: Daniel Axtens
> >
> >All 64-bit objects need to specify the flag to be compiled correctly, we
> >just don't need it for 32-bit objects. GCC just ignored it, but clang
>
On Fri, Jan 11, 2019 at 05:06:12PM +1100, Michael Ellerman wrote:
> Tyrel Datwyler writes:
> > It is basically the predecessor to PAPR "Power Architecture Platform
> > Reference".
> > Which the LoPAPR document is available through power.org. Not sure if there
> > is
> > any desire to adopt PAPR
On Sat, Jan 12, 2019 at 08:44:26AM +0300, Dan Carpenter wrote:
> On Sat, Jan 12, 2019 at 11:30:35AM +1100, Balbir Singh wrote:
> > On Wed, Jan 09, 2019 at 01:23:29PM +0300, Dan Carpenter wrote:
> > > There is a typo so we accidentally allocate enough memory for a pointer
> > > when we wanted to
On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> Could you please define interesting frame on top a bit more? Usually
> the topmost return address is in LR
There is no reliable way (other than DWARF unwind info) to find out where
the value of LR at function entry currently lives
On Fri, Sep 14, 2018 at 03:20:18PM -0700, Nick Desaulniers wrote:
> On Fri, Sep 14, 2018 at 2:56 PM Segher Boessenkool
> wrote:
> > On Sat, Sep 15, 2018 at 06:43:05AM +1000, Nicholas Piggin wrote:
> > > On Fri, 14 Sep 2018 11:03:38 -0700
> > > Nick Desaulniers wro
On Sat, Sep 15, 2018 at 06:43:05AM +1000, Nicholas Piggin wrote:
> On Fri, 14 Sep 2018 11:03:38 -0700
> Nick Desaulniers wrote:
>
> > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley wrote:
> > > Last time this was proposed there was an issue reported:
> > >
> > >
> > >
On Fri, Sep 14, 2018 at 10:47:08AM -0700, Nick Desaulniers wrote:
> On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley wrote:
> > 10:addis r12,r12,(-RELACOUNT)@ha
> > - cmpdi r12,RELACOUNT@l
> > + cmpdi r12,(RELACOUNT)@l
>
> Yep, as we can see above, when RELACOUNT is negated,
On Mon, Sep 17, 2018 at 12:15:08PM +, Christophe Leroy wrote:
> I would have liked to use -mstack-protector-guard=tls
> -mstack-protector-guard-reg=r2
> -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)
> but I have
> not found how set the value of offsetof(struct
On Mon, Jan 28, 2019 at 07:20:43PM +0100, Christophe Leroy wrote:
> I'm wondering what CONFIG_RTAS is. It makes use of one of the SPRN_SPRG,
> ie SPRN_SPRG2.
>
> What are the CPUs concerned by RTAS ? Is there any of the old CPUs which
> have only 4 SPRGs (eg the 601), or could we use one in
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 defconf
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
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
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
&
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
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
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
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=246457
> which is part of GCC 7.
>
> It also only applies to TARGET_ARCH12, which I am guessing
> corresponds to
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
>
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
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
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_de
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
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
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
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
On Wed, Feb 20, 2019 at 10:18:38PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> >> Balbir Singh writes:
> >> > Fair enough, my point was that the compiler can help out. I'll see
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
> + * 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
ncient history by now, and good riddance :-)
> Signed-off-by: Joel Stanley
Acked-by: Segher Boessenkool
Segher
On Fri, Feb 08, 2019 at 05:12:21PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Thu, Feb 07, 2019 at 10:53:13PM +1100, Michael Ellerman wrote:
> >> Chandan reported that fstests' generic/026 test hit a crash:
> >
> >> The instruction dump d
On Fri, Feb 08, 2019 at 02:02:24PM +1100, Michael Ellerman wrote:
> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
> b/arch/powerpc/kernel/dt_cpu_ftrs.c
> index 8be3721d9302..a1acccd25839 100644
> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
> @@ -675,12
Hi all,
On Sat, Feb 16, 2019 at 09:55:11PM +1100, Balbir Singh wrote:
> On Thu, Feb 14, 2019 at 05:23:39PM +1100, Michael Ellerman wrote:
> > In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> > rather than just checking that the value is non-zero, e.g.:
> >
> > static
On Thu, Feb 07, 2019 at 05:59:48PM +1100, Andrew Donnellan wrote:
> On 7/2/19 5:37 pm, Segher Boessenkool wrote:
> >On Thu, Feb 07, 2019 at 04:33:23PM +1100, Andrew Donnellan wrote:
> >>Some older gccs ( >>cause a spurious uninitialised variable warning in dt_cpu_ftrs.c:
On Thu, Feb 07, 2019 at 04:33:23PM +1100, Andrew Donnellan wrote:
> Some older gccs ( cause a spurious uninitialised variable warning in dt_cpu_ftrs.c:
>
> arch/powerpc/kernel/dt_cpu_ftrs.c: In function
> ‘cpufeatures_process_feature’:
> arch/powerpc/kernel/dt_cpu_ftrs.c:686:7: warning: ‘m’
On Thu, Feb 07, 2019 at 10:53:13PM +1100, Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
> The instruction dump decodes as:
> subfic r6,r5,8
> rlwinm r6,r6,3,0,28
> ldbrx r9,0,r3
> ldbrx r10,0,r4<-
>
> Which shows us doing an 8 byte load
On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> Balbir Singh writes:
> > Fair enough, my point was that the compiler can help out. I'll see what
> > -Wconversion finds on my local build :)
>
> I get about 43MB of warnings here :)
Yes, -Wconversion complains about a lot of
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
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
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
&
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,
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 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),
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
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 +-
>
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
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 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
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!
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 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,
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
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, 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:
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 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 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 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:
>
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 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 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 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
801 - 900 of 1471 matches
Mail list logo
