* Aneesh Kumar K.V [2020-08-02 19:51:41]:
> Srikar Dronamraju writes:
> > * Aneesh Kumar K.V [2020-07-31 16:49:14]:
> >
> >
> > If its just to eliminate node 0, then we have 2 other probably better
> > solutions.
> > 1. Dont mark node 0 as spl (currently still in mm-tree and a result in
> >
On Fri, Jul 31, 2020 at 04:52:05PM +0530, Aneesh Kumar K.V wrote:
> On PowerNV platforms we always have 1:1 mapping between chip ID and
> firmware group id. Use the helper to convert firmware group id to
> node id instead of directly using chip ID as Linux node id.
>
> NOTE: This doesn't have any
Hi Michael,
On 04/08/20 6:38 am, Michael Ellerman wrote:
> Sandipan Das writes:
>> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>>> Sachin Sant writes:
> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
> On 02/08/20 4:45 pm, Sachin Sant wrote:
>> pkey_exec_prot test from linuxppc
Hi Joel,
On Tue, Jun 30, 2020 at 11:29:35AM +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc:
On Tue, Aug 04, 2020 at 12:03:46AM -0700, Nicolin Chen wrote:
> On Tue, Aug 04, 2020 at 12:22:53PM +0800, Shengjiu Wang wrote:
>
> > > > Btw, do we need similar change for TRIGGER_STOP?
> > >
> > > This is a good question. It is better to do change for STOP,
> > > but I am afraid that there is no
On Tue, Aug 4, 2020 at 12:07 PM Joel Stanley wrote:
>
> Messy:
>
> $ git grep "define DBG(" arch/powerpc/ |grep -v print
> arch/powerpc/kernel/crash_dump.c:#define DBG(fmt...)
> arch/powerpc/kernel/iommu.c:#define DBG(...)
> arch/powerpc/kernel/legacy_serial.c:#define DBG(fmt...) do { } while(0)
On 23/07/2020 20:56, Nicholas Piggin wrote:
> With the previous patch, lockdep hardirq state changes should not be
> redundant. Softirq state changes already follow that pattern.
>
> So warn on unexpected enable-when-enabled or disable-when-disabled
> conditions, to catch possible errors or
On 04/08/20 11:46, pet...@infradead.org wrote:
> On Tue, Aug 04, 2020 at 09:03:07AM +0530, Srikar Dronamraju wrote:
>> On Power9 a pair of cores can be presented by the firmware as a big-core
>> for backward compatibility reasons, with 4 threads per (small) core and 8
>> threads per big-core.
On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote:
> cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> most architectures. One of the users of cpu_smt_mask(), would be to
> identify idle-cores. On Power9, a pair of cores can be presented by the
> firmware as a
On Tue, Aug 04, 2020 at 09:03:07AM +0530, Srikar Dronamraju wrote:
> On Power9 a pair of cores can be presented by the firmware as a big-core
> for backward compatibility reasons, with 4 threads per (small) core and 8
> threads per big-core. cpu_smt_mask() should generally point to the cpu mask
>
On 07/15/2020 01:04 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Prepare for switching VDSO to generic C implementation in following
patch. Here, we:
- Modify __get_datapage() to take an offset
- Prepare the helpers to call the C VDSO functions
- Prepare the required callbacks for
On 05/08/2020 13:04, Leonardo Bras wrote:
> From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the number of
> outputs from "ibm,query-pe-dma-windows" go from 5 to 6.
>
> This change of output size is meant to expand the address size of
> largest_available_block PE TCE from 32-bit to
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> > From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the
> > number of
>
> outputs from "ibm,query-pe-dma-windows" go from 5 to 6.
>
> This change of output size is meant to expand the address size of
> largest_available_block PE
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> Move the window-removing part of remove_ddw into a new function
> (remove_dma_window), so it can be used to remove other DMA windows.
>
> It's useful for removing DMA windows that don't create
> DIRECT64_PROPNAME
> property, like the
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> Create defines to help handling ibm,ddw-applicable values, avoiding
> confusion about the index of given operations.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 43 --
>
> 1
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> On LoPAR "DMA Window Manipulation Calls", it's recommended to remove
> the
> default DMA window for the device, before attempting to configure a
> DDW,
> in order to make the maximum resources available for the next DDW to
> be
> created.
>
Move the window-removing part of remove_ddw into a new function
(remove_dma_window), so it can be used to remove other DMA windows.
It's useful for removing DMA windows that don't create DIRECT64_PROPNAME
property, like the default DMA window from the device, which uses
"ibm,dma-window".
Greg Kurz writes:
> On Tue, 04 Aug 2020 23:35:10 +1000
> Michael Ellerman wrote:
>> There is a bit of history to this code, but not in a good way :)
>>
>> Michael Roth writes:
>> > For a power9 KVM guest with XIVE enabled, running a test loop
>> > where we hotplug 384 vcpus and then unplug
On 05/08/2020 13:04, Leonardo Bras wrote:
> Create defines to help handling ibm,ddw-applicable values, avoiding
> confusion about the index of given operations.
>
> Signed-off-by: Leonardo Bras
> Tested-by: David Dai
Reviewed-by: Alexey Kardashevskiy
> ---
>
On Mon, 3 Aug 2020 12:07:19 +1000, Michael Ellerman wrote:
> Some of our tests use VSX or newer VMX instructions, so need to be
> skipped on older CPUs to avoid SIGILL'ing.
>
> Similarly TAR was added in v2.07, and the PMU event used in the stcx
> fail test only works on Power8 or later.
Applied
On Wed, 22 Jul 2020 12:24:22 +1000, Michael Ellerman wrote:
> The assembler says:
> arch/powerpc/kernel/head_40x.S:623: Warning: invalid register expression
>
> It's objecting to the use of r0 as the RA argument. That's because
> when RA = 0 the literal value 0 is used, rather than the content
>From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the number of
outputs from "ibm,query-pe-dma-windows" go from 5 to 6.
This change of output size is meant to expand the address size of
largest_available_block PE TCE from 32-bit to 64-bit, which ends up
shifting page_size and
On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
default DMA window for the device, before attempting to configure a DDW,
in order to make the maximum resources available for the next DDW to be
created.
This is a requirement for using DDW on devices in which hypervisor
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> Create defines to help handling ibm,ddw-applicable values, avoiding
> confusion about the index of given operations.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 43 --
>
> 1
On Mon, 3 Aug 2020 17:54:08 +1000, Oliver O'Halloran wrote:
> Initialising the value before using it is generally regarded as a good
> idea so do that.
Applied to powerpc/next.
[1/1] powerpc/powernv/sriov: Fix use of uninitialised variable
On 05/08/2020 13:04, Leonardo Bras wrote:
> Move the window-removing part of remove_ddw into a new function
> (remove_dma_window), so it can be used to remove other DMA windows.
>
> It's useful for removing DMA windows that don't create DIRECT64_PROPNAME
> property, like the default DMA window
On 05/08/2020 13:04, Leonardo Bras wrote:
> On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
> default DMA window for the device, before attempting to configure a DDW,
> in order to make the maximum resources available for the next DDW to be
> created.
>
> This is a
There are some devices in which a hypervisor may only allow 1 DMA window
to exist at a time, and in those cases, a DDW is never created to them,
since the default DMA window keeps using this resource.
LoPAR recommends this procedure:
1. Remove the default DMA window,
2. Query for which configs
Create defines to help handling ibm,ddw-applicable values, avoiding
confusion about the index of given operations.
Signed-off-by: Leonardo Bras
Tested-by: David Dai
---
arch/powerpc/platforms/pseries/iommu.c | 43 --
1 file changed, 26 insertions(+), 17 deletions(-)
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Currently, initrd image is reserved very early during setup and then it
> might be relocated and re-reserved after the initial physical memory
> mapping is created. The "late" reservation of memblock verifies that mapped
>
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20200804
x86_64 randconfig-a001-20200804
x86_64 randconfig-a004-20200804
x86_64 randconfig-a005-20200804
x86_64
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start_pfn = memblock_region_memory_base_pfn(reg);
> end_pfn =
Michael Ellerman writes:
> Greg Kurz writes:
>> On Tue, 04 Aug 2020 23:35:10 +1000
>> Michael Ellerman wrote:
>>> There is a bit of history to this code, but not in a good way :)
>>>
>>> Michael Roth writes:
>>> > For a power9 KVM guest with XIVE enabled, running a test loop
>>> > where we
> On 04-Aug-2020, at 11:01 PM, Sandipan Das wrote:
>
> On distros using older glibc versions, the pkey tests
> encounter build failures due to redefinition of the
> pkey syscall numbers.
>
> For compatibility, commit 743f3544fffb added a wrapper
> for the gettid() syscall and included
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory size calculation in cma_early_percent_memory() traverses
> memblock.memory rather than simply call memblock_phys_mem_size(). The
> comment in that function suggests that at some point there should have been
> call
allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200804
i386 randconfig-a004-20200804
i386
Quoting Michael Ellerman (2020-08-04 22:07:08)
> Greg Kurz writes:
> > On Tue, 04 Aug 2020 23:35:10 +1000
> > Michael Ellerman wrote:
> >> There is a bit of history to this code, but not in a good way :)
> >>
> >> Michael Roth writes:
> >> > For a power9 KVM guest with XIVE enabled, running a
On distros using older glibc versions, the pkey tests
encounter build failures due to redefinition of the
pkey syscall numbers.
For compatibility, commit 743f3544fffb added a wrapper
for the gettid() syscall and included syscall.h if the
version of glibc used is older than 2.30. This leads
to
On 04/08/20 5:53 pm, Michael Ellerman wrote:
> Sandipan Das writes:
>> On 04/08/20 6:38 am, Michael Ellerman wrote:
>>> Sandipan Das writes:
On 03/08/20 4:32 pm, Michael Ellerman wrote:
> Sachin Sant writes:
>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das
>>> wrote:
>>>
From: Colin Ian King
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
arch/powerpc/oprofile/cell/spu_task_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/oprofile/cell/spu_task_sync.c
On 07/16/2020 02:59 AM, Michael Ellerman wrote:
Christophe Leroy writes:
The VDSO datapage and the text pages are always located immediately
next to each other, so it can be hardcoded without an indirection
through __kernel_datapage_offset
In order to ease things, move the data page in
On PPC64, the TOC pointer needs to be saved and restored.
Suggested-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
v9: New.
I'm not sure this is really needed, I can't see the VDSO C code doing
anything with r2, at least on ppc64_defconfig.
So I let you decide whether you take it or
For VDSO32 on PPC64, we create a fake 32 bits config, on the same
principle as MIPS architecture, in order to get the correct parts of
the different asm header files.
With the C VDSO, the performance is slightly lower, but it is worth
it as it will ease maintenance and evolution, and also brings
Provides __kernel_clock_gettime64() on vdso32. This is the
64 bits version of __kernel_clock_gettime() which is
y2038 compliant.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 9 +
arch/powerpc/kernel/vdso32/vdso32.lds.S| 1 +
cpu_relax() need to be in asm/vdso/processor.h to be used by
the C VDSO generic library.
Move it there.
Signed-off-by: Christophe Leroy
---
v9: Forgot to remove cpu_relax() from processor.h in v8
---
arch/powerpc/include/asm/processor.h | 13 ++---
Joel Stanley writes:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc: sta...@vger.kernel.org # v3.14
> Signed-off-by: Joel
Joel Stanley writes:
> On Tue, 4 Aug 2020 at 00:57, Oliver O'Halloran wrote:
>>
>> When building with W=1 we get the following warning:
>>
>> arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
>> arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
* pet...@infradead.org [2020-08-04 12:45:20]:
> On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote:
> > cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> > most architectures. One of the users of cpu_smt_mask(), would be to
> > identify idle-cores. On Power9,
Sandipan Das writes:
> On 04/08/20 6:38 am, Michael Ellerman wrote:
>> Sandipan Das writes:
>>> On 03/08/20 4:32 pm, Michael Ellerman wrote:
Sachin Sant writes:
>> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>> pkey_exec_prot
On Tue, Aug 04, 2020 at 05:40:07PM +0530, Srikar Dronamraju wrote:
> * pet...@infradead.org [2020-08-04 12:45:20]:
>
> > On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote:
> > > cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> > > most architectures. One of
This is the nineth version of a series to switch powerpc VDSO to
generic C implementation.
Main changes since v8 are:
- Dropped the patches which put the VDSO datapage in front of VDSO text in the
mapping
- Adds a second stack frame because the caller doesn't set one, at least on
PPC64
- Saving
Prepare for switching VDSO to generic C implementation in following
patch. Here, we:
- Prepare the helpers to call the C VDSO functions
- Prepare the required callbacks for the C VDSO functions
- Prepare the clocksource.h files to define VDSO_ARCH_CLOCKMODES
- Add the C trampolines to the generic
Recently random.h started including percpu.h (see commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity")), which broke corenet64_smp_defconfig:
In file included from /linux/arch/powerpc/include/asm/paca.h:18,
from
On Mon, Aug 3, 2020 at 9:52 PM Laurent Dufour wrote:
>
> > @@ -603,6 +606,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
> > }
> >
> > lmb_set_nid(lmb);
> > + lmb->flags |= DRCONF_MEM_ASSIGNED;
> > +
> > block_sz = memory_block_size_bytes();
> >
> > /*
Hi Mike,
There is a bit of history to this code, but not in a good way :)
Michael Roth writes:
> For a power9 KVM guest with XIVE enabled, running a test loop
> where we hotplug 384 vcpus and then unplug them, the following traces
> can be seen (generally within a few loops) either from the
On Tue, Aug 4, 2020 at 12:29 AM Laurent Dufour wrote:
>
[...]
> > lmb_set_nid(lmb);
> > lmb->flags |= DRCONF_MEM_ASSIGNED;
> > + if (dt_update) {
> > + ret = drmem_update_dt();
> > + if (ret)
> > + pr_warn("%s fail to update dt, but
Hi Mike,
>
> The memory size calculation in kvm_cma_reserve() traverses memblock.memory
> rather than simply call memblock_phys_mem_size(). The comment in that
> function suggests that at some point there should have been call to
> memblock_analyze() before memblock_phys_mem_size() could be used.
Fix smatch warning:
drivers/soc/fsl/qe/ucc.c:526
ucc_set_tdm_rxtx_clk() warn: unsigned 'tdm_num' is never less than zero.
'tdm_num' is u32 type, never less than zero.
Signed-off-by: Wang Hai
---
drivers/soc/fsl/qe/ucc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, 04 Aug 2020 23:35:10 +1000
Michael Ellerman wrote:
> Hi Mike,
>
> There is a bit of history to this code, but not in a good way :)
>
> Michael Roth writes:
> > For a power9 KVM guest with XIVE enabled, running a test loop
> > where we hotplug 384 vcpus and then unplug them, the
On Tue, 4 Aug 2020 23:05:58 +1000, Michael Ellerman wrote:
> Recently random.h started including percpu.h (see commit
> f227e3ec3b5c ("random32: update the net random state on interrupt and
> activity")), which broke corenet64_smp_defconfig:
>
> In file included from
60 matches
Mail list logo
