Re: [PATCH 1/2] powerpc: string: implement optimized memset variants

On 30 March 2017 at 12:46, Naveen N. Rao wrote: > Also, with a simple module to memset64() a 1GB vmalloc'ed buffer, here > are the results: > generic:0.245315533 seconds time elapsed( +- 1.83% ) > optimized: 0.169282701 seconds time elapsed

Re: [RFC PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

On 04/04/2017 07:33 PM, Aneesh Kumar K.V wrote: > This patch adds support for gigantic pages in ppc64. We also updates > gigantic_page_supported helper such that arch can override it. Seems like only radix based 1GB is considered as gigantic page in this implementation. What about the existing

[PATCH V2] powerpc/hugetlb: Add ABI defines for supported HugeTLB page sizes

This just adds user space exported ABI definitions for 2MB, 16MB, 1GB, 16GB non default huge page sizes to be used with mmap() system call. Signed-off-by: Anshuman Khandual --- These defined values will be used along with MAP_HUGETLB while calling mmap() system call

Re: [PATCH v2] KVM: PPC: Book3S PR: Do not fail emulation with mtspr/mfspr for unknown SPRs

On Tue, Apr 04, 2017 at 12:05:03PM +0200, Thomas Huth wrote: > According to the PowerISA 2.07, mtspr and mfspr should not always > generate an illegal instruction exception when being used with an > undefined SPR, but rather treat the instruction as a NOP or inject a > privilege exception in some

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote: Hi, +#define IMC_MAX_CHIPS 32 +#define IMC_MAX_PMUS 32 +#define IMC_MAX_PMU_NAME_LEN 256 I've noticed this is used as both the maximum length for event names and event value strings. Would

Re: [PATCH kernel] powerpc/iommu: Do not call PageTransHuge() on tail pages

On Wednesday 05 April 2017 08:29 AM, Alexey Kardashevskiy wrote: On 04/04/17 19:26, Aneesh Kumar K.V wrote: Alexey Kardashevskiy writes: The CMA pages migration code does not support compound pages at the moment so it performs few tests before proceeding to actual page

Re: [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function

On 04/04/2017 04:11 AM, Michael Ellerman wrote: > Haren Myneni writes: > >> [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function >> >> nx842_powernv_function is points to nx842_icswx_function and >> will be point to VAS function which will be added

Re: [PATCH kernel] powerpc/iommu: Do not call PageTransHuge() on tail pages

On 04/04/17 19:26, Aneesh Kumar K.V wrote: > Alexey Kardashevskiy writes: > >> The CMA pages migration code does not support compound pages at >> the moment so it performs few tests before proceeding to actual page >> migration. >> >> One of the tests - PageTransHuge() - has

[RFC PATCH 3/3] powerpc/pseries: Always enable SMP when building pseries

The pseries platform supports Power4 and later CPUs, all of which are multithreaded and/or multicore. In practice no one ever builds a SMP=n kernel for these machines. So as we did for powernv, have the pseries platform imply SMP=y. Signed-off-by: Michael Ellerman ---

[RFC PATCH 2/3] powerpc/powernv: Always enable SMP when building powernv

The powernv platform supports Power7 and later CPUs, all of which are multithreaded and multicore. As such we never build a SMP=n kernel for those machines, other than possibly for debugging or running in a simulator. In the debugging case we can get a similar effect by booting with nr_cpus=1,

[RFC PATCH 1/3] powerpc: Allow platforms to force-enable CONFIG_SMP

Of the 64-bit Book3S platforms, only powermac supports booting on an actual non-SMP system. The other platforms can be built with SMP disabled, but it doesn't make a lot of sense given the CPUs they support are all multicore or multithreaded. So give platforms the option of forcing SMP=y.

Re: POWER4 - who has one?

Hi Michael, PowerPc 970 as classified as Power4 too, because is it a pure derivate. If need i have a 970MP Ciao Luigi Da: Linuxppc-dev per conto di Michael Ellerman

Re: POWER4 - who has one?

On Apr 04 2017, Michael Ellerman wrote: > Quick quiz, who still has a POWER4? Does a G5 qualify? > And if so are you running mainline on it? Always following latest -rc. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Implement vas_init() and vas_exit() functions for a new VAS module. > This VAS module is essentially a library for other device drivers > and kernel users of the NX coprocessors like NX-842 and NX-GZIP. > In the future this will be

Re: [PATCH v4 02/11] VAS: Define macros, register fields and structures

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Define macros for the VAS hardware registers and bit-fields as well > as couple of data structures needed by the VAS driver. > > Signed-off-by: Sukadev Bhattiprolu > +++ b/arch/powerpc/platforms/powernv/vas.h > @@ -0,0 +1,387 @@ > +/*

Re: POWER4 - who has one?

On 4/4/17, Michael Ellerman wrote: > Hi folks, > > Quick quiz, who still has a POWER4? > > And if so are you running mainline on it? Not the same thing, but I have a box on two 970MP > > cheers >

Re: [PATCH guest kernel] vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check

On Tue, 4 Apr 2017 20:12:45 +1000 Alexey Kardashevskiy wrote: > On 25/03/17 23:25, Alexey Kardashevskiy wrote: > > On 25/03/17 07:29, Alex Williamson wrote: > >> On Fri, 24 Mar 2017 17:44:06 +1100 > >> Alexey Kardashevskiy wrote: > >> > >>> The existing SPAPR

Re: [PATCH 06/12] powerpc/xive: Native exploitation of the XIVE interrupt controller

On Tue, 2017-04-04 at 23:03 +1000, Michael Ellerman wrote: > > >  14 files changed, 2186 insertions(+), 12 deletions(-) > > I'm not going to review this in one go, given it's 10:30pm already. Well, good, I was about to send (well tomorrow morning actually) v2 hoping it was going to be final

Re: [RFC PATCH 1/7] mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at

The patch series is not yet send to linux-mm. Once I get feedback on the approach used, I will resend this to linux-mm. Also if there is sufficient interest we could also get nohash hugetlb migration to work. But I avoided doing that in this series, because of my inability to test the

[RFC PATCH 7/7] powerpc/hugetlb: Enable hugetlb migration for ppc64

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/platforms/Kconfig.cputype | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 382c3dd86d6d..c0ca27521679 100644 ---

[RFC PATCH 3/7] mm/hugetlb: export hugetlb_entry_migration helper

We will be using this later from the ppc64 code. Change the return type to bool. Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 1 + mm/hugetlb.c| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git

[RFC PATCH 4/7] mm/follow_page_mask: Add support for hugepage directory entry

The defaul implementation prints warning and returns NULL. We will add ppc64 support in later patches Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 3 +++ mm/gup.c| 33 + mm/hugetlb.c|

[RFC PATCH 5/7] mm/follow_page_mask: Add support for hugetlb pgd entries.

ppc64 supports pgd hugetlb entries. Add code to handle hugetlb pgd entries to follow_page_mask so that ppc64 can switch to it to handle hugetlbe entries. Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 3 +++ mm/gup.c| 7 +++

[RFC PATCH 6/7] powerpc/hugetlb: Add code to support to follow huge page directory entries

Add follow_huge_pd implementation for ppc64. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/hugetlbpage.c | 42 ++ 1 file changed, 42 insertions(+) diff --git a/arch/powerpc/mm/hugetlbpage.c

[RFC PATCH 2/7] mm/follow_page_mask: Split follow_page_mask to smaller functions.

Makes code reading easy. No functional changes in this patch. Signed-off-by: Aneesh Kumar K.V --- mm/gup.c | 148 +++ 1 file changed, 91 insertions(+), 57 deletions(-) diff --git a/mm/gup.c b/mm/gup.c

[RFC PATCH 1/7] mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at

The right interface to use to set a hugetlb pte entry is set_huge_pte_at. Use that instead of set_pte_at. Signed-off-by: Aneesh Kumar K.V --- mm/migrate.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/mm/migrate.c

[RFC PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

This patch adds support for gigantic pages in ppc64. We also updates gigantic_page_supported helper such that arch can override it. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/book3s/64/hugetlb.h | 9 + arch/powerpc/mm/hugetlbpage.c

Re: [PATCH] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

On 04/04/2017 02:03 PM, Aneesh Kumar K.V wrote: > > > On Tuesday 04 April 2017 11:33 AM, Anshuman Khandual wrote: >> 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

Re: [PATCH 02/12] powerpc: Sync opal-api.h

On Tue, 2017-04-04 at 22:20 +1000, Michael Ellerman wrote: > Benjamin Herrenschmidt writes: > > ... > > Give me some change log ! Well, the subject says it all :-) Sync the API with the latest OPAL :-) > > Signed-off-by: Benjamin Herrenschmidt

Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms

Hi Michael, Just a couple of basic things to check: - was the dtb updated to the newest? - is the qman node present? This should be easily visible in /proc/device-tree/soc@ffe00/qman@318000. --- Best Regards, Laurentiu On 04/04/2017 08:03 AM, Michael Ellerman wrote: > Horia Geantă

POWER4 - who has one?

Hi folks, Quick quiz, who still has a POWER4? And if so are you running mainline on it? cheers

Re: [PATCH 06/12] powerpc/xive: Native exploitation of the XIVE interrupt controller

Benjamin Herrenschmidt writes: > The XIVE interrupt controller is the new interrupt controller > found in POWER9. It supports advanced virtualization capabilities > among other things. > > Currently we use a set of firmware calls that simulate the old > "XICS" interrupt

Re: [PATCH] tty/hvc_console: fix console lock ordering with spinlock

On 4/4/17, Michael Ellerman wrote: > Denis Kirjanov writes: > >> hvc_remove() takes a spin lock first then acquires the console >> semaphore. This situation can easily lead to a deadlock scenario >> where we call scheduler with spin lock held. > >

[bug report] ibmvnic: Cleanup failure path in ibmvnic_open

[ This patch changed the code from using multiple come-from label names to using a single err label. Both are terrible ways to do error handling. Come-From Labels: Come-from labels look like this: foo = alloc(); if (!foo) goto alloc_failed; The

Re: [PATCH 02/12] powerpc: Sync opal-api.h

Benjamin Herrenschmidt writes: ... Give me some change log ! > Signed-off-by: Benjamin Herrenschmidt > --- > arch/powerpc/include/asm/opal-api.h| 302 > - It looks like you've just copied it over in its

Re: [PATCH 1/2] powerpc: string: implement optimized memset variants

"Naveen N. Rao" writes: > (generic) is with Matt's arch-independent patches applied. Profiling > indicates that most of the overhead is actually with the lzo > decompression... > > Also, with a simple module to memset64() a 1GB vmalloc'ed buffer, here > are the

Re: [PATCH] tty/hvc_console: fix console lock ordering with spinlock

Denis Kirjanov writes: > hvc_remove() takes a spin lock first then acquires the console > semaphore. This situation can easily lead to a deadlock scenario > where we call scheduler with spin lock held. Have you actually hit the deadlock? Because that code's been like

Re: [PATCH 5/5] crypto/nx: Add P9 NX specific error codes for 842 engine

Haren Myneni writes: > [PATCH 5/5] crypto/nx: Add P9 NX specific error codes for 842 engine > > This patch adds changes for checking P9 specific 842 engine > error codes. These errros are reported in co-processor status > block (CSB) for failures. But you just enabled

Re: [PATCH 3/5] crypto/nx: Create nx842_delete_coproc function

Haren Myneni writes: > [PATCH 3/5] crypto/nx: Create nx842_delete_coproc function > > Move deleting coprocessor info upon exit or failure to > nx842_delete_coproc(). Naming again, this deletes *all* the coprocs, so the name should be plural. cheers

Re: [PATCH 2/5] crypto/nx: Create nx842_cfg_crb function

Haren Myneni writes: > [PATCH 2/5] crypto/nx: Create nx842_cfg_crb function > > Configure CRB is moved to nx842_cfg_crb() so that it can be > used for icswx function and VAS function which will be added > later. Buy a vowel! :) nx842_configure_crb() is fine. cheers

Re: [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function

Haren Myneni writes: > [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function > > nx842_powernv_function is points to nx842_icswx_function and > will be point to VAS function which will be added later for > P9 NX support. I know it's nit-picking but can

Re: [PATCH 4/5] crypto/nx: Add P9 NX support for 842 compression engine.

Hi Haren, A few comments ... Haren Myneni writes: > diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h > index 4e5a470..7315621 100644 > --- a/arch/powerpc/include/asm/vas.h > +++ b/arch/powerpc/include/asm/vas.h > @@ -19,6 +19,8 @@ >

Re: [PATCH guest kernel] vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check

On 25/03/17 23:25, Alexey Kardashevskiy wrote: > On 25/03/17 07:29, Alex Williamson wrote: >> On Fri, 24 Mar 2017 17:44:06 +1100 >> Alexey Kardashevskiy wrote: >> >>> The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and >>> VFIO_SPAPR_TCE_v2_IOMMU types to the

[PATCH v2] KVM: PPC: Book3S PR: Do not fail emulation with mtspr/mfspr for unknown SPRs

According to the PowerISA 2.07, mtspr and mfspr should not always generate an illegal instruction exception when being used with an undefined SPR, but rather treat the instruction as a NOP or inject a privilege exception in some cases, too - depending on the SPR number. Also turn the printk here

Re: [PATCH] raid6/altivec: adding vpermxor implementation for raid6 Q syndrome

Daniel Axtens writes: >> In that function, the flow is: >> pagefault_disable(); >> enable_kernel_altivec(); >> >> pagefault_enable(); >> >> There are a few things that it would be nice (but by no means essential) >> to find out: >> - what is the difference between

Re: [PATCH] powerpc/misc: fix exported functions that reference the TOC

Benjamin Herrenschmidt writes: > On Mon, 2017-04-03 at 23:29 +1000, Michael Ellerman wrote: >> The other option would be just to make a rule that anything EXPORT'ed >> must use _GLOBAL_TOC(). > > Can we enforce that somewhat at build time ? Yeah I had a quick look at doing

Re: [PATCH kernel] powerpc/iommu: Do not call PageTransHuge() on tail pages

Alexey Kardashevskiy writes: > The CMA pages migration code does not support compound pages at > the moment so it performs few tests before proceeding to actual page > migration. > > One of the tests - PageTransHuge() - has VM_BUG_ON_PAGE(PageTail()) as > it should be called on

Re: [PATCH] powerpc/mm: Add missing global TLBI if cxl is active

Frederic Barrat writes: > Commit 4c6d9acce1f4 ("powerpc/mm: Add hooks for cxl") converted local > TLBIs to global if the cxl driver is active. It is necessary because > the CAPP snoops invalidations to forward them to the PSL on the cxl > adapter. > However one path

Re: [PATCH] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

On Tuesday 04 April 2017 11:33 AM, Anshuman Khandual wrote: 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 --- These defined values will be

Re: [PATCH] KVM: PPC: Book3S PR: Do not fail emulation with mtspr/mfspr for unknown SPRs

On 04.04.2017 08:25, Paul Mackerras wrote: > On Mon, Apr 03, 2017 at 01:23:15PM +0200, Thomas Huth wrote: >> According to the PowerISA 2.07, mtspr and mfspr should not generate >> an illegal instruction exception when being used with an undefined SPR, >> but rather treat the instruction as a NOP,

Re: [PATCH] KVM: PPC: Book3S PR: Do not fail emulation with mtspr/mfspr for unknown SPRs

On Mon, Apr 03, 2017 at 01:23:15PM +0200, Thomas Huth wrote: > According to the PowerISA 2.07, mtspr and mfspr should not generate > an illegal instruction exception when being used with an undefined SPR, > but rather treat the instruction as a NOP, inject a privilege exception > or an emulation

Re: [PATCH] KVM: PPC: Book3S PR: Do not always inject facility unavailable exceptions

On Mon, Apr 03, 2017 at 01:28:34PM +0200, Thomas Huth wrote: > KVM should not inject a facility unavailable exception into the guest > when it tries to execute a mtspr/mfspr instruction for an SPR that > is unavailable, and the vCPU is *not* running in PRoblem state. > > It's right that we inject

[PATCH] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

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 --- These defined values will be used along with MAP_HUGETLB while calling mmap() system call if