These 2 fields track whether user process has used Altivec/VSX
registers or not. They are used by kernel to setup signal frame
on user stack correctly regarding vector part.
CRIU(Checkpoint and Restore In User space) builds signal frame
for restored process. It will need this export information to
>>
>> I was about to queue this for next, when I noticed that checkpatch is
>> complaining/warning lots about these patches. Can you please a round of
>> checkpatch and fix what makes sense.
>>
>> Kind regards
>> Uffe
>
> [Lu Yangbo-B47093] Sorry about this, Uffe...
No worries!
> Should I ignore
memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:
1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
all the LMBs of the guest, but that is
On Tue 05-04-16 12:05:47, Sukadev Bhattiprolu wrote:
[...]
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index d991b9e..081f679 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -81,6 +81,13 @@ static int __hugepte_alloc(struct
From: Zhaoxiu Zeng
Use runtime patching for ppc64, lifted from hweight_64
Signed-off-by: Zhaoxiu Zeng
---
arch/powerpc/include/asm/bitops.h | 11
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/parity_64.S | 107 ++
arch/powerpc/lib/p
Michal Hocko writes:
> [ text/plain ]
> On Tue 05-04-16 12:05:47, Sukadev Bhattiprolu wrote:
> [...]
>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index d991b9e..081f679 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -
From: Hou Zhiqiang
Disable the subsector (4KiB) erase granularity to speed up the erase
operation.
Signed-off-by: Hou Zhiqiang
---
arch/powerpc/configs/85xx-hw.config | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/85xx-hw.config
b/arch/powerpc/configs/85xx-hw.config
On Wed 06-04-16 15:39:17, Aneesh Kumar K.V wrote:
> Michal Hocko writes:
>
> > [ text/plain ]
> > On Tue 05-04-16 12:05:47, Sukadev Bhattiprolu wrote:
> > [...]
> >> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> >> index d991b9e..081f679 100644
> >> --- a/arch/power
Hi Peter,
> Ah, so sometihng like:
>
> struct pt_regs *regs = task_pt_regs();
> int index = CPUACCT_USAGE_SYSTEM;
>
> if (regs && user_mode(regs))
> index = CPUACCT_USAGE_USER;
>
> should work, right?
Looks good, and the patch below does fix the oops for me.
An
This patchset fixes three issues found with perf probe on ppc64le:
1. 'perf test kallsyms' failure on ppc64le (reported by Michael
Ellerman). This was due to the symbols being fixed up during symbol
table load. This is fixed in patch 2 by delaying symbol fixup until
later.
2. perf probe function of
So far, we used to treat probe point offsets as being offset from the
LEP. However, userspace applications (objdump/readelf) always show
disassembly and offsets from the function GEP. This is confusing to the
user as we will end up probing at an address different from what the
user expects when loo
ppc64le functions have a Global Entry Point (GEP) and a Local Entry
Point (LEP). While placing a probe, we always prefer the LEP since it
catches function calls through both the GEP and the LEP. In order to do
this, we fixup the function entry points during elf symbol table lookup
to point to the L
* Anton Blanchard [2016-04-06 21:59:50]:
> Looks good, and the patch below does fix the oops for me.
>
> Anton
> --
>
> task_pt_regs() can return NULL for kernel threads, so add a check.
> This fixes an oops at boot on ppc64.
>
> Signed-off-by: Anton Blanchard
Works for me too.
Reported-and
Now that the FMAN mac driver has been merged the fman node is relevant.
The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
and 2 with fixed 1 Giga SGMII links.
Signed-off-by: Valentin Longchamp
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 39 ++
The commit dc37374 move a lot of device tree files into fsl directory
fixing Makefile for cuImage target only. Unfortunately there are others
target which require to embebbed device tree into the kernel image
(i.e. dtbImage.%). So use a more generic approach.
Signed-off-by: Alessio Igor Bogani
--
On Wed, Apr 06, 2016 at 06:02:58PM +0530, Naveen N. Rao wrote:
> ppc64le functions have a Global Entry Point (GEP) and a Local Entry
> Point (LEP). While placing a probe, we always prefer the LEP since it
> catches function calls through both the GEP and the LEP. In order to do
> this, we fixup the
On Tue, 5 Apr 2016 21:46:44 +0800
Yongji Xie wrote:
> This patch enables mmapping MSI-X tables if
> hardware supports interrupt remapping which
> can ensure that a given pci device can only
> shoot the MSIs assigned for it.
>
> Signed-off-by: Yongji Xie
> ---
> drivers/vfio/pci/vfio_pci.c
Enables the use of multiple transmit and receive scrqs allowing the ibmvnic
driver to take advantage of multiqueue functionality. To achieve this, the
driver must implement the process of negotiating the maximum number of
queues allowed by the server. Initially, the driver will attempt to login
wit
Hi,
On Wed, Mar 30, 2016 at 03:43:40PM -0500, Li Yang wrote:
> Hi Brian,
>
> Could you help to review and pull in this patch and the Kconfig update
> after this patch(https://patchwork.ozlabs.org/patch/557389/)? It
It's probably best for Boris to apply this now.
> stated a dependency in the no
From: "Naveen N. Rao"
Date: Mon, 4 Apr 2016 22:31:32 +0530
> Building BPF samples is failing with the below error:
...
> Fix this by including the necessary header file.
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: David S. Miller
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael El
From: "Naveen N. Rao"
Date: Mon, 4 Apr 2016 22:31:33 +0530
> While at it, remove the generation of .s files and fix some typos in the
> related comment.
>
> Cc: Alexei Starovoitov
> Cc: David S. Miller
> Cc: Daniel Borkmann
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael Ellerman
> Signed-o
From: "Naveen N. Rao"
Date: Mon, 4 Apr 2016 22:31:34 +0530
> Add the necessary definitions for building bpf samples on ppc.
>
> Since ppc doesn't store function return address on the stack, modify how
> PT_REGS_RET() and PT_REGS_FP() work.
>
> Also, introduce PT_REGS_IP() to access the instruc
From: "Naveen N. Rao"
Date: Tue, 5 Apr 2016 15:32:53 +0530
> JMP_JSET tests incorrectly used BPF_JNE. Fix the same.
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: "David S. Miller"
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Signed-off-by: Naveen
From: "Naveen N. Rao"
Date: Tue, 5 Apr 2016 15:32:54 +0530
> Unsigned Jump-if-Greater-Than.
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: "David S. Miller"
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Signed-off-by: Naveen N. Rao
Applied.
_
From: "Naveen N. Rao"
Date: Tue, 5 Apr 2016 15:32:56 +0530
> Some of these tests proved useful with the powerpc eBPF JIT port due to
> sign-extended 16-bit immediate loads. Though some of these aspects get
> covered in other tests, it is better to have explicit tests so as to
> quickly tag the p
Excerpts from Guilherme G. Piccoli's message of 2016-03-18 16:49:06 -0500:
> +static int get_phb_number(struct device_node *dn)
...
> +/* try fixed PHB numbering first, by checking archs and reading
> + * the respective device-tree property. */
> +if (machine_is(pseries)) {
> +
From: "Naveen N. Rao"
Date: Tue, 5 Apr 2016 15:32:55 +0530
> BPF_ALU32 and BPF_ALU64 tests for adding two 32-bit values that results in
> 32-bit overflow.
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: "David S. Miller"
> Cc: Ananth N Mavinakayanahalli
> Cc: Michael Ellerman
> Cc:
> -Original Message-
> From: Srikar Dronamraju [mailto:sri...@linux.vnet.ibm.com]
> Sent: Wednesday, April 06, 2016 9:27 PM
> To: Anton Blanchard
> Cc: Peter Zijlstra ; Ingo Molnar ;
> t...@linutronix.de; efa...@gmx.de; hte...@gmail.com;
> linux-ker...@vger.kernel.org; t...@kernel.org; t
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Wednesday, April 06, 2016 12:53 PM
> To: Li Yang
> Cc: Scott Wood ; Raghav Dogra ;
> linux-...@lists.infradead.org; linuxppc-dev ;
> Prabhakar Kushwaha ; Raghav Dogra
> ; Jaiprakash Singh ; Boris
> Bre
On Wed, 2016-04-06 at 15:37 +0200, Valentin Longchamp wrote:
> Now that the FMAN mac driver has been merged the fman node is relevant.
>
> The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
> and 2 with fixed 1 Giga SGMII links.
>
> Signed-off-by: Valentin Longchamp
> ---
>
On 04/06/2016 04:38 PM, Ian Munsie wrote:
+/* try fixed PHB numbering first, by checking archs and reading
+ * the respective device-tree property. */
+if (machine_is(pseries)) {
+regs = of_get_property(dn, "reg", NULL);
+if (regs)
+return (int)(be32_to_cpu
On Wed, 2016-04-06 at 18:14 +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang
>
> Disable the subsector (4KiB) erase granularity to speed up the erase
> operation.
>
> Signed-off-by: Hou Zhiqiang
> ---
> arch/powerpc/configs/85xx-hw.config | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Hey guys - our system test team opened a defect on this, since Ubuntu (as it stands) is broken now with CAPI Flash cards.
Dion opened bug https://bugzilla.linux.ibm.com/show_bug.cgi?id=140054 .
So - this is important. You need to tested to confirm that this is in-fact the root cause of Dion's
Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
changed the pci_dn struct by removing its EEH-related members.
As part of this clean-up, DDW mechanism was modified to read the device
configuration address from eeh_dev struct.
As a consequence, now if we disable EEH mechanis
This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.
The function eeh_add_device_early() is used to perform EEH initialization in
devices added later on the system, like in hotplug/DLPAR scenarios. Since the
commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
On 02/04/2016 03:30 AM, Gavin Shan wrote:
On Wed, Feb 03, 2016 at 10:26:36AM -0200, Guilherme G. Piccoli wrote:
On 02/02/2016 09:48 PM, Gavin Shan wrote:
Gavin, thanks very much for the clarification. So, we can interchange
edev->config_addr with pdn->pci_ext_config_space ?
This would solve the
On Wed, Apr 06, 2016 at 09:20:04PM -0300, Guilherme G. Piccoli wrote:
>This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.
>
>The function eeh_add_device_early() is used to perform EEH initialization in
>devices added later on the system, like in hotplug/DLPAR scenarios. Since the
>commit
On Wed, Apr 06, 2016 at 09:20:05PM -0300, Guilherme G. Piccoli wrote:
>Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
>changed the pci_dn struct by removing its EEH-related members.
>As part of this clean-up, DDW mechanism was modified to read the device
>configuration addr
On 04/06/2016 09:48 PM, Gavin Shan wrote:
On Wed, Apr 06, 2016 at 09:20:05PM -0300, Guilherme G. Piccoli wrote:
Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
Signed-off-by: Guilherme G. Piccoli
Reviewed-by: Gavin Shan
Thanks, Guilherme. Please make sure if it needs
Excerpts from Guilherme G. Piccoli's message of 2016-04-06 16:51:43 -0500:
> And in the case a virtual PHB grabs the bitmap before, we just need to
> add Michael's suggested check and fallback to bitmap PHB numbering in
> this case.
>
> Do you think this is enough to avoid issues with cxl'a virt
On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:
> + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
> tev->point.offset += PPC64LE_LEP_OFFSET;
uprobes check against kallsysms? Am I missing something here?
Ananth
_
This patch series enables HugeTLB page migration on POWER platform.
This series has some core VM changes (patch 1, 2, 3) and some powerpc
specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions
and inputs are welcome.
Anshuman Khandual (10):
mm/mmap: Replace SHM_HUGE_MASK with MAP_H
Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
page implementation at the PGD level. This is also true for functions
like 'follow_page_mask' which is called from move_pages() system call.
This lack of PGD l
The commit 091d0d55b286 ("shm: fix null pointer deref when userspace
specifies invalid hugepage size") had replaced MAP_HUGE_MASK with
SHM_HUGE_MASK. Though both of them contain the same numeric value of
0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one
in the context. Hence chang
This just adds user space exported ABI definitions for both 16MB and
16GB non default huge page sizes to be used with mmap() system call.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/include/uapi/asm/mman.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm
Currently the function 'huge_pte_offset' has just got one version for all
possible configurations and platforms. This change splits that function
into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation
and the other one for everything else. This change is again one of the
prerequi
This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION
depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB
or not along with config option MIGRATION. In turn, it turns on the
'hugepage_migration_supported' function which is checked for feature
presence during HugeTLB p
This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S
platforms with 64K page size implementation. Existing arch specific
functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc'
and 'huge_pte_offset' are no longer required and are removed with
this change.
Signed-off-by
Currently the function 'huge_pte_alloc' has got two versions, one for the
BOOK3S server and the other one for the BOOK3E embedded platforms. This
change splits only the BOOK3S server version into two parts, one for the
ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for
everything
This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.
Signed-off-by: Anshuman Khandual
---
Arch override function 'follow_huge_addr' is called from 'follow_page_mask'
looking out for the associated page struct. Right now, it does not support
the FOLL_GET option.
With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask'
to use generic 'follow_huge_*' functions instead of
follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
fetch the page struct during 'follow_page_mask' call. There are possible
race conditions faced by these functions which arise out of simultaneous
calls of move_pages() and freeing of huge pages. This was fixed partly
by the pre
Hi Scott,
Thanks for your comments.
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: 2016年4月7日 6:01
> To: Zhiqiang Hou ; linuxppc-dev@lists.ozlabs.org;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au
> Cc: Mingkai Hu
> Subject: Re: [PATCH] powe
On 06/04/16 23:49, Scott Wood wrote:
> On Wed, 2016-04-06 at 15:37 +0200, Valentin Longchamp wrote:
>> Now that the FMAN mac driver has been merged the fman node is relevant.
>>
>> The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
>> and 2 with fixed 1 Giga SGMII links.
>>
>> S
In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the
spec states that values of 9900-9905 can be returned, indicating that
software should delay for 10^x (where x is the last digit, i.e. 990x)
milliseconds and attempt the call again. Currently, the kernel doesn't
know about this, an
The RTAS calls "ibm,configure-pe" and "ibm,configure-bridge" perform the
same actions, however the former can skip configuration if unnecessary.
The existing code treats them as different tokens even though only one
will ever be called. Refactor this by making a single token that is
assigned durin
On 2016/04/07 10:00AM, Ananth N wrote:
> On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:
>
> > + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
> > tev->point.offset += PPC64LE_LEP_OFFSET;
>
> uprobes check against kallsysms? Am I missing som
57 matches
Mail list logo
