Re: [PATCH 0/6] KVM: PPC: e500: Fine-tuning for two function implementations

On Sun, Aug 28, 2016 at 07:09:57PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 19:01:02 +0200 > > Several update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > Use

Re: [PATCH 0/6] KVM: PPC: e500: Fine-tuning for two function implementations

On Sun, Aug 28, 2016 at 07:09:57PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 19:01:02 +0200 > > Several update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > Use kmalloc_array() in

Re: [PATCH v2] powerpc: move hmi.c to arch/powerpc/kvm/

rather than CONFIG_PPC_BOOK3S_64. The sibling_subcore_state is also > included in struct paca_struct only if KVM is supported by the kernel. > > Cc: Daniel Axtens <d...@axtens.net> > Cc: Michael Ellerman <m...@ellerman.id.au> > Cc: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com>

Re: [PATCH v2] powerpc: move hmi.c to arch/powerpc/kvm/

rather than CONFIG_PPC_BOOK3S_64. The sibling_subcore_state is also > included in struct paca_struct only if KVM is supported by the kernel. > > Cc: Daniel Axtens > Cc: Michael Ellerman > Cc: Mahesh Salgaonkar > Cc: Paul Mackerras > Cc: linuxppc-...@lists.ozlabs.org >

Re: [PATCH 6/6] KVM: PPC: e500: Rename jump labels in kvmppc_e500_tlb_init()

On Sun, Aug 28, 2016 at 07:19:22PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:45:26 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring

Re: [PATCH 6/6] KVM: PPC: e500: Rename jump labels in kvmppc_e500_tlb_init()

On Sun, Aug 28, 2016 at 07:19:22PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:45:26 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring With this I get a compile error: CC

Re: mm: Initialise per_cpu_nodestats for all online pgdats at boot

On Thu, Aug 04, 2016 at 10:24:04AM +0100, Mel Gorman wrote: > Paul Mackerras and Reza Arbab reported that machines with memoryless nodes > fails when vmstats are refreshed. Paul reported an oops as follows > > [1.713998] Unable to handle kernel paging request for dat

Re: mm: Initialise per_cpu_nodestats for all online pgdats at boot

On Thu, Aug 04, 2016 at 10:24:04AM +0100, Mel Gorman wrote: > Paul Mackerras and Reza Arbab reported that machines with memoryless nodes > fails when vmstats are refreshed. Paul reported an oops as follows > > [1.713998] Unable to handle kernel paging request for dat

Crashes in refresh_zone_stat_thresholds when some nodes have no memory

gt;per_cpu_nodestats is NULL. Avoid crashing on machines which have memoryless nodes by checking for non-NULL pgdat->per_cpu_nodestats. Signed-off-by: Paul Mackerras <pau...@ozlabs.org> --- diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h index 6137719..48b2780 100644 --- a/inclu

Crashes in refresh_zone_stat_thresholds when some nodes have no memory

hing on machines which have memoryless nodes by checking for non-NULL pgdat->per_cpu_nodestats. Signed-off-by: Paul Mackerras --- diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h index 6137719..48b2780 100644 --- a/include/linux/vmstat.h +++ b/include/linux/vmstat.h @@ -184,8 +184,9

Re: [PATCH] powerpc: inline current_stack_pointer()

On Mon, May 23, 2016 at 07:17:38PM +0200, Gabriel Paubert wrote: > On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote: > > current_stack_pointeur() is a single instruction function. it > > It is not worth breaking the execution flow with a bl/blr for a > > single instruction > > Are

Re: [PATCH] powerpc: inline current_stack_pointer()

On Mon, May 23, 2016 at 07:17:38PM +0200, Gabriel Paubert wrote: > On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote: > > current_stack_pointeur() is a single instruction function. it > > It is not worth breaking the execution flow with a bl/blr for a > > single instruction > > Are

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR named PSSCR is

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR named PSSCR is

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

unusual exit conditions, but if there are any they should be documented too. Reviewed-by: Paul Mackerras <pau...@samba.org>

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

unusual exit conditions, but if there are any they should be documented too. Reviewed-by: Paul Mackerras

Re: [PATCH v2 2/3] /dev/dax, core: file operations and dax-mmap

On Wed, May 18, 2016 at 10:07:19AM +0200, Hannes Reinecke wrote: > On 05/18/2016 12:19 AM, Dan Williams wrote: > > On Tue, May 17, 2016 at 3:57 AM, Johannes Thumshirn > > wrote: > >> On Sat, May 14, 2016 at 11:26:29PM -0700, Dan Williams wrote: > >>> The "Device DAX" core

Re: [PATCH v2 2/3] /dev/dax, core: file operations and dax-mmap

On Wed, May 18, 2016 at 10:07:19AM +0200, Hannes Reinecke wrote: > On 05/18/2016 12:19 AM, Dan Williams wrote: > > On Tue, May 17, 2016 at 3:57 AM, Johannes Thumshirn > > wrote: > >> On Sat, May 14, 2016 at 11:26:29PM -0700, Dan Williams wrote: > >>> The "Device DAX" core enables dax mappings of

Re: [PATCH v2] kvm-pr: manage single-step mode

On Fri, Apr 08, 2016 at 06:05:00PM +0200, Laurent Vivier wrote: > Until now, when we connect gdb to the QEMU gdb-server, the > single-step mode is not managed. > > This patch adds this, only for kvm-pr: > > If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the > MSR (MSR_SE)

Re: [PATCH v2] kvm-pr: manage single-step mode

On Fri, Apr 08, 2016 at 06:05:00PM +0200, Laurent Vivier wrote: > Until now, when we connect gdb to the QEMU gdb-server, the > single-step mode is not managed. > > This patch adds this, only for kvm-pr: > > If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the > MSR (MSR_SE)

Regression in v4.6-rc due to SCSI multipath change

Current upstream kernels fail to boot on my POWER8 server with multipath SCSI disks and IPR host bus adapters. What happens is that the system finds each disk twice (as normal) and then prints messages like this: [2.827761] sd 1:2:4:0: alua: supports implicit TPGS [2.827875] sd 1:2:4:0:

Regression in v4.6-rc due to SCSI multipath change

Current upstream kernels fail to boot on my POWER8 server with multipath SCSI disks and IPR host bus adapters. What happens is that the system finds each disk twice (as normal) and then prints messages like this: [2.827761] sd 1:2:4:0: alua: supports implicit TPGS [2.827875] sd 1:2:4:0:

Re: [PATCH 1/3] powerpc/powernv: Move CHECK_HMI_INTERRUPT to exception-64s header

On Mon, Feb 29, 2016 at 05:52:58PM +0530, Shreyas B. Prabhu wrote: > CHECK_HMI_INTERRUPT is used to check for HMI's in reset vector. Move > the macro to a common location (exception-64s.h) > This patch does not change any functionality. Comments below... > diff --git

Re: [PATCH 1/3] powerpc/powernv: Move CHECK_HMI_INTERRUPT to exception-64s header

On Mon, Feb 29, 2016 at 05:52:58PM +0530, Shreyas B. Prabhu wrote: > CHECK_HMI_INTERRUPT is used to check for HMI's in reset vector. Move > the macro to a common location (exception-64s.h) > This patch does not change any functionality. Comments below... > diff --git

Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro

On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote: > Before entering any idle state which can result in a state loss > we currently save the context in the stack before entering idle. > Encapsulate these steps in a macro IDLE_STATE_PREP. Move this > and other macros to commonly

Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro

On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote: > Before entering any idle state which can result in a state loss > we currently save the context in the stack before entering idle. > Encapsulate these steps in a macro IDLE_STATE_PREP. Move this > and other macros to commonly

Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro

On Fri, Mar 18, 2016 at 08:23:24PM +0530, Shreyas B Prabhu wrote: > Hi Paul, > > On 03/17/2016 04:45 PM, Paul Mackerras wrote: > > On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote: > >> Before entering any idle state which can result in a state los

Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro

On Fri, Mar 18, 2016 at 08:23:24PM +0530, Shreyas B Prabhu wrote: > Hi Paul, > > On 03/17/2016 04:45 PM, Paul Mackerras wrote: > > On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote: > >> Before entering any idle state which can result in a state los

Re: [kernel] powerpc: Make vmalloc_to_phys() public

On Mon, Jan 25, 2016 at 04:46:03PM +1100, Michael Ellerman wrote: > On Thu, 2016-21-01 at 07:35:08 UTC, Alexey Kardashevskiy wrote: > > This makes vmalloc_to_phys() public as there will be another user > > (in-kernel VFIO acceleration) for it soon. > > > > As a part of future little optimization,

Re: [kernel] powerpc: Make vmalloc_to_phys() public

On Mon, Jan 25, 2016 at 04:46:03PM +1100, Michael Ellerman wrote: > On Thu, 2016-21-01 at 07:35:08 UTC, Alexey Kardashevskiy wrote: > > This makes vmalloc_to_phys() public as there will be another user > > (in-kernel VFIO acceleration) for it soon. > > > > As a part of future little optimization,

Bad backport of "net: Fix skb_set_peeked use-after-free bug" in 3.18.23

Commit d9a1133495b4 ("net: Fix skb_set_peeked use-after-free bug") in 3.18.23 claims to be a backport of commit a0a2a6602496, but in fact the patch is identical to commit 738ac1ebb96d ("net: Clone skb before setting peeked flag"), which is the commit that introduces the use-after-free bug that

Bad backport of "net: Fix skb_set_peeked use-after-free bug" in 3.18.23

Commit d9a1133495b4 ("net: Fix skb_set_peeked use-after-free bug") in 3.18.23 claims to be a backport of commit a0a2a6602496, but in fact the patch is identical to commit 738ac1ebb96d ("net: Clone skb before setting peeked flag"), which is the commit that introduces the use-after-free bug that

Re: [PATCH] kvm: remove unused variable 'vcpu_book3s'

On Tue, Dec 01, 2015 at 08:42:10PM -0300, Geyslan G. Bem wrote: > The vcpu_book3s struct is assigned but never used. So remove it. > > Signed-off-by: Geyslan G. Bem Thanks, applied to my kvm-ppc-next branch. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH] kvm: remove unused variable 'vcpu_book3s'

On Tue, Dec 01, 2015 at 08:42:10PM -0300, Geyslan G. Bem wrote: > The vcpu_book3s struct is assigned but never used. So remove it. > > Signed-off-by: Geyslan G. Bem Thanks, applied to my kvm-ppc-next branch. Paul. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu

On Sat, Dec 05, 2015 at 06:19:46PM -0800, Paul E. McKenney wrote: > > As in the following? (And yes, I was confused by the fact that the > docbook header was in front of a differently-named macro!) > > Thanx, Paul That looks great! Have

Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu

On Sat, Dec 05, 2015 at 06:19:46PM -0800, Paul E. McKenney wrote: > > As in the following? (And yes, I was confused by the fact that the > docbook header was in front of a differently-named macro!) > > Thanx, Paul That looks great! Have

Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu

On Wed, Nov 18, 2015 at 11:13:28AM -0800, Paul E. McKenney wrote: > On Fri, Nov 06, 2015 at 01:17:17PM +1100, Alexey Kardashevskiy wrote: [snip] > > Still, is my approach correct? What does the comment for > > lockless_dereference() actally mean - it won't work together with > > RCU at all or this

Re: [RFC] kvm - possible out of bounds

On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote: > Hello, > > I have found a possible out of bounds reading in > arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate > function). pteg[] array could be accessed twice using the i variable > after the for iteration. What

Re: [RFC] kvm - possible out of bounds

On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote: > Hello, > > I have found a possible out of bounds reading in > arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate > function). pteg[] array could be accessed twice using the i variable > after the for iteration. What

Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry_rcu

On Wed, Nov 18, 2015 at 11:13:28AM -0800, Paul E. McKenney wrote: > On Fri, Nov 06, 2015 at 01:17:17PM +1100, Alexey Kardashevskiy wrote: [snip] > > Still, is my approach correct? What does the comment for > > lockless_dereference() actally mean - it won't work together with > > RCU at all or this

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > I am not seeing a sync there, but I really have to defer to the > > maintainers on this one. I could easily have missed one. > > So x86 implies a full barrier

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > I am not seeing a sync there, but I really have to defer to the > > maintainers on this one. I could easily have missed one. > > So x86 implies a full barrier

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > > Should we not take this opportunity to get rid of these open-coded wait > loops? > > > Does this work? No, on Book3S HV (POWER8) the VM hangs immediately after the kernel brings up all the secondary vCPUs, and is then

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > @@ -2018,17 +2017,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) > } while (single_task_running() && ktime_before(cur, stop)); > } > > - for (;;) { > - prepare_to_wait(>wq, ,

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2015 at 09:28:08AM +0200, Daniel Wagner wrote: > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c > > index 2280497..f534e15 100644 > > --- a/arch/powerpc/kvm/book3s_hv.c > > +++

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > @@ -2018,17 +2017,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) > } while (single_task_running() && ktime_before(cur, stop)); > } > > - for (;;) { > - prepare_to_wait(>wq, ,

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > > Should we not take this opportunity to get rid of these open-coded wait > loops? > > > Does this work? No, on Book3S HV (POWER8) the VM hangs immediately after the kernel brings up all the secondary vCPUs, and is then

Re: [PATCH v3 2/4] KVM: use simple waitqueue for vcpu->wq

On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2015 at 09:28:08AM +0200, Daniel Wagner wrote: > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c > > index 2280497..f534e15 100644 > > --- a/arch/powerpc/kvm/book3s_hv.c > > +++

Re: [PATCH 15/19] KVM: PPC: e500: fix handling local_sid_lookup result

On Thu, Sep 24, 2015 at 04:00:23PM +0200, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Re: [PATCH 15/19] KVM: PPC: e500: fix handling local_sid_lookup result

On Thu, Sep 24, 2015 at 04:00:23PM +0200, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n

On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gard...@canonical.com wrote: > From: Tim Gardner > > commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() > routine available") neglected to define an empty inline replacement for > enable_kernel_vsx() when CONFIG_VSX=n. If code

Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n

On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gard...@canonical.com wrote: > From: Tim Gardner > > commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() > routine available") neglected to define an empty inline replacement for > enable_kernel_vsx() when

Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote: > > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote: > > > That would fix the problem with smp_mb__after_unlock_lock(), but not > > > the original

Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote: > > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote: > > > That would fix the problem with smp_mb__after_unlock_lock(), but not > > > the original

Re: [PATCH] vfio: Enable VFIO device for powerpc

On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote: > > > On 13.08.15 03:15, David Gibson wrote: > > ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is > > used to handle any necessary interactions between KVM and VFIO. > > > > Currently that device is built

Re: linux-next: manual merge of the kvm-ppc tree with the tip tree

Hi Stephen, On Mon, Aug 24, 2015 at 03:59:54PM +1000, Stephen Rothwell wrote: > Hi Alexander, > > Today's linux-next merge of the kvm-ppc tree got a conflict in: > > arch/powerpc/kvm/book3s_hv.c > > between commit: > > c56dadf39761 ("sched/preempt, powerpc, kvm: Use need_resched() instead

Re: linux-next: manual merge of the kvm-ppc tree with the tip tree

Hi Stephen, On Mon, Aug 24, 2015 at 03:59:54PM +1000, Stephen Rothwell wrote: Hi Alexander, Today's linux-next merge of the kvm-ppc tree got a conflict in: arch/powerpc/kvm/book3s_hv.c between commit: c56dadf39761 (sched/preempt, powerpc, kvm: Use need_resched() instead of

Re: [PATCH] vfio: Enable VFIO device for powerpc

On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote: On 13.08.15 03:15, David Gibson wrote: ec53500f kvm: Add VFIO device added a special KVM pseudo-device which is used to handle any necessary interactions between KVM and VFIO. Currently that device is built on x86 and

Re: [PATCH] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c

On Mon, Aug 10, 2015 at 11:27:31AM -0400, Nicholas Krause wrote: > This fixes the wrapper functions kvm_umap_hva_hv and the function > kvm_unmap_hav_range_hv to return the return value of the function > kvm_handle_hva or kvm_handle_hva_range that they are wrapped to > call internally rather then

Re: [PATCH] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c

On Mon, Aug 10, 2015 at 11:27:31AM -0400, Nicholas Krause wrote: This fixes the wrapper functions kvm_umap_hva_hv and the function kvm_unmap_hav_range_hv to return the return value of the function kvm_handle_hva or kvm_handle_hva_range that they are wrapped to call internally rather then

Re: [PATCH RESEND v4 3/3] kvm/powerpc: Export HCALL reason codes

On Mon, Jun 15, 2015 at 10:26:09AM +0530, Hemant Kumar wrote: > For perf to analyze the KVM events like hcalls, we need the > hypervisor calls and their codes to be exported through uapi. Why? The hcall codes are defined externally to the kernel (in the PAPR document) and won't change. They're

Re: [PATCH RESEND v4 1/3] kvm/powerpc: Export kvm exit reasons

On Mon, Jun 15, 2015 at 10:26:07AM +0530, Hemant Kumar wrote: > To analyze the kvm exits with perf, we will need to map the exit codes > with the exit reasons. Such a mapping exists today in trace_book3s.h. > Currently its not exported to perf. > > This patch moves these kvm exit reasons and

Re: [PATCH RESEND v4 3/3] kvm/powerpc: Export HCALL reason codes

On Mon, Jun 15, 2015 at 10:26:09AM +0530, Hemant Kumar wrote: For perf to analyze the KVM events like hcalls, we need the hypervisor calls and their codes to be exported through uapi. Why? The hcall codes are defined externally to the kernel (in the PAPR document) and won't change. They're

Re: [PATCH RESEND v4 1/3] kvm/powerpc: Export kvm exit reasons

On Mon, Jun 15, 2015 at 10:26:07AM +0530, Hemant Kumar wrote: To analyze the kvm exits with perf, we will need to map the exit codes with the exit reasons. Such a mapping exists today in trace_book3s.h. Currently its not exported to perf. This patch moves these kvm exit reasons and their

[tip:perf/core] perf: Remove myself from MAINTAINERS entry

Commit-ID: 09a216ea5c528356797dc12ab35234922a6c02be Gitweb: http://git.kernel.org/tip/09a216ea5c528356797dc12ab35234922a6c02be Author: Paul Mackerras AuthorDate: Thu, 28 May 2015 16:17:57 +1000 Committer: Ingo Molnar CommitDate: Thu, 28 May 2015 10:43:03 +0200 perf: Remove myself from

[PATCH] perf: Remove myself from MAINTAINERS entry

I haven't been working on perf for a while, so remove my name from the MAINTAINERS entry for it. Signed-off-by: Paul Mackerras --- diff --git a/MAINTAINERS b/MAINTAINERS index 781e099..cd37cb1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7604,7 +7604,6 @@ F:kernel/delayacct.c

[PATCH] perf: Remove myself from MAINTAINERS entry

I haven't been working on perf for a while, so remove my name from the MAINTAINERS entry for it. Signed-off-by: Paul Mackerras pau...@samba.org --- diff --git a/MAINTAINERS b/MAINTAINERS index 781e099..cd37cb1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7604,7 +7604,6 @@ F:kernel

[tip:perf/core] perf: Remove myself from MAINTAINERS entry

Commit-ID: 09a216ea5c528356797dc12ab35234922a6c02be Gitweb: http://git.kernel.org/tip/09a216ea5c528356797dc12ab35234922a6c02be Author: Paul Mackerras pau...@samba.org AuthorDate: Thu, 28 May 2015 16:17:57 +1000 Committer: Ingo Molnar mi...@kernel.org CommitDate: Thu, 28 May 2015 10:43:03

Re: [RFC PATCH v6] Documentation/arch: Add Documentation/arch-features.txt

On Wed, May 13, 2015 at 03:48:42PM +0200, Ingo Molnar wrote: > > Updated patch attached - I've added a few more features to the last > table, and restructured the explanations, now every feature > description also lists the Kconfig variable that it's tracking, e.g.: > > irq time acct:

Re: [RFC PATCH v6] Documentation/arch: Add Documentation/arch-features.txt

On Wed, May 13, 2015 at 03:48:42PM +0200, Ingo Molnar wrote: Updated patch attached - I've added a few more features to the last table, and restructured the explanations, now every feature description also lists the Kconfig variable that it's tracking, e.g.: irq time acct:

Re: [PATCH kernel v9 28/32] powerpc/mmu: Add userspace-to-physical addresses translation cache

On Thu, Apr 30, 2015 at 04:34:55PM +1000, David Gibson wrote: > On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote: > > We are adding support for DMA memory pre-registration to be used in > > conjunction with VFIO. The idea is that the userspace which is going to > > run a guest

Re: [PATCH kernel v9 28/32] powerpc/mmu: Add userspace-to-physical addresses translation cache

On Thu, Apr 30, 2015 at 04:34:55PM +1000, David Gibson wrote: On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote: We are adding support for DMA memory pre-registration to be used in conjunction with VFIO. The idea is that the userspace which is going to run a guest may

Re: [PATCH] ring-buffer: More precise time stamps for nested writes

On Fri, Mar 27, 2015 at 12:04:15PM -0400, Steven Rostedt wrote: > On Fri, 27 Mar 2015 00:38:43 -0500 > "Suresh E. Warrier" wrote: > > > > But for now, what can be done is to have > > > a flag that is set that will implement this or not. Using > > > static_branch() to implement it such that when

Re: [PATCH] ring-buffer: More precise time stamps for nested writes

On Fri, Mar 27, 2015 at 12:04:15PM -0400, Steven Rostedt wrote: On Fri, 27 Mar 2015 00:38:43 -0500 Suresh E. Warrier warr...@linux.vnet.ibm.com wrote: But for now, what can be done is to have a flag that is set that will implement this or not. Using static_branch() to implement it

Re: [PATCH v3 12/24] powerpc/iommu/powernv: Release replaced TCE

On Thu, Jan 29, 2015 at 08:21:53PM +1100, Alexey Kardashevskiy wrote: > At the moment writing new TCE value to the IOMMU table fails with EBUSY > if there is a valid entry already. However PAPR specification allows > the guest to write new TCE value without clearing it first. > > Another problem

Re: [PATCH v3 12/24] powerpc/iommu/powernv: Release replaced TCE

On Thu, Jan 29, 2015 at 08:21:53PM +1100, Alexey Kardashevskiy wrote: At the moment writing new TCE value to the IOMMU table fails with EBUSY if there is a valid entry already. However PAPR specification allows the guest to write new TCE value without clearing it first. Another problem this

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu->wq

On Mon, Jan 19, 2015 at 12:41:00PM -0200, Marcelo Tosatti wrote: > On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote: > > > static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc) > > > { > > > - DEFINE_WAIT(wait); > > > + DEFINE_SWAITER(wait); > > > > > > - prepare_to_wait(>wq,

Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq

On Mon, Jan 19, 2015 at 12:41:00PM -0200, Marcelo Tosatti wrote: On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote: static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc) { - DEFINE_WAIT(wait); + DEFINE_SWAITER(wait); - prepare_to_wait(vc-wq, wait,

Re: [PATCH v3 4/4] powernv: powerpc: Add winkle support for offline cpus

On Thu, Dec 04, 2014 at 12:58:23PM +0530, Shreyas B. Prabhu wrote: > Winkle is a deep idle state supported in power8 chips. A core enters > winkle when all the threads of the core enter winkle. In this state > power supply to the entire chiplet i.e core, private L2 and private L3 > is turned off.

Re: [PATCH v3 3/4] powernv: cpuidle: Redesign idle states management

On Thu, Dec 04, 2014 at 12:58:22PM +0530, Shreyas B. Prabhu wrote: > Deep idle states like sleep and winkle are per core idle states. A core > enters these states only when all the threads enter either the > particular idle state or a deeper one. There are tasks like fastsleep > hardware bug

Re: [PATCH v3 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states

dle driver or the hotplug > path need be bothered about this workaround. > > They will be taken care of by the core powernv code. > > Originally-by: Srivatsa S. Bhat > Signed-off-by: Preeti U. Murthy > Signed-off-by: Shreyas B. Prabhu Reviewed-by: Paul Mackerras -- To unsu

Re: [PATCH] arch: powerpc: kernel: sys_ppc32.c: Remove unused function

On Sun, Dec 07, 2014 at 06:56:54PM +0100, Rickard Strandqvist wrote: > Remove the function compat_sys_mmap2() that is not used anywhere. It's referenced in 64-bit kernels from arch/powerpc/kernel/systbl.S, via the SYS32ONLY(mmap2) line in arch/powerpc/include/asm/systbl.h. Paul. -- To

Re: [PATCH] arch: powerpc: kernel: sys_ppc32.c: Remove unused function

On Sun, Dec 07, 2014 at 06:56:54PM +0100, Rickard Strandqvist wrote: Remove the function compat_sys_mmap2() that is not used anywhere. It's referenced in 64-bit kernels from arch/powerpc/kernel/systbl.S, via the SYS32ONLY(mmap2) line in arch/powerpc/include/asm/systbl.h. Paul. -- To unsubscribe

Re: [PATCH v3 2/4] powerpc/powernv: Enable Offline CPUs to enter deep idle states

about this workaround. They will be taken care of by the core powernv code. Originally-by: Srivatsa S. Bhat sriva...@mit.edu Signed-off-by: Preeti U. Murthy pre...@linux.vnet.ibm.com Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Reviewed-by: Paul Mackerras pau...@samba.org

Re: [PATCH v3 3/4] powernv: cpuidle: Redesign idle states management

On Thu, Dec 04, 2014 at 12:58:22PM +0530, Shreyas B. Prabhu wrote: Deep idle states like sleep and winkle are per core idle states. A core enters these states only when all the threads enter either the particular idle state or a deeper one. There are tasks like fastsleep hardware bug

Re: [PATCH v3 4/4] powernv: powerpc: Add winkle support for offline cpus

On Thu, Dec 04, 2014 at 12:58:23PM +0530, Shreyas B. Prabhu wrote: Winkle is a deep idle state supported in power8 chips. A core enters winkle when all the threads of the core enter winkle. In this state power supply to the entire chiplet i.e core, private L2 and private L3 is turned off. As a

Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs

On Mon, Dec 01, 2014 at 04:02:14PM +1100, Michael Ellerman wrote: > On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: > > The bounds check for nodeid in cache_alloc_node gives false > > positives on machines where the node IDs are not contiguous, leading > > to

[PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs

) call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras --- v2: include the oops message in the patch description mm/slab

Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs

On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: > (2014/12/01 7:16), Paul Mackerras wrote: > >The bounds check for nodeid in cache_alloc_node gives false > >positives on machines where the node IDs are not contiguous, leading > >to a panic at bo

[PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs

, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7

[PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs

, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c

Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs

On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: (2014/12/01 7:16), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8

[PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs

in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org --- v2: include the oops message

Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs

On Mon, Dec 01, 2014 at 04:02:14PM +1100, Michael Ellerman wrote: On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time

Re: [PATCH v2 3/4] powernv: cpuidle: Redesign idle states management

On Tue, Nov 25, 2014 at 04:47:58PM +0530, Shreyas B. Prabhu wrote: [snip] > +2: > + /* Sleep or winkle */ > + li r7,1 > + mfspr r8,SPRN_PIR > + /* > + * The last 3 bits of PIR represents the thread id of a cpu > + * in power8. This will need adjusting for power7. >

Re: [PATCH v2 3/4] powernv: cpuidle: Redesign idle states management

On Tue, Nov 25, 2014 at 04:47:58PM +0530, Shreyas B. Prabhu wrote: [snip] +2: + /* Sleep or winkle */ + li r7,1 + mfspr r8,SPRN_PIR + /* + * The last 3 bits of PIR represents the thread id of a cpu + * in power8. This will need adjusting for power7. +

[PATCH] Fix thinko in iov_iter_single_seg_count

gle_seg_count() would just return i->count and the loop made no progress and continued forever. Cc: sta...@vger.kernel.org # 3.16+ Signed-off-by: Paul Mackerras --- diff --git a/mm/iov_iter.c b/mm/iov_iter.c index eafcf60..e34a3cb 100644 --- a/mm/iov_iter.c +++ b/mm/iov_iter.c @@ -911,9

[PATCH] Fix thinko in iov_iter_single_seg_count

() would just return i-count and the loop made no progress and continued forever. Cc: sta...@vger.kernel.org # 3.16+ Signed-off-by: Paul Mackerras pau...@samba.org --- diff --git a/mm/iov_iter.c b/mm/iov_iter.c index eafcf60..e34a3cb 100644 --- a/mm/iov_iter.c +++ b/mm/iov_iter.c @@ -911,9 +911,9

Re: Regression in 3.15 on POWER8 with multipath SCSI

On Mon, Jun 30, 2014 at 01:35:20PM +0200, Hannes Reinecke wrote: > On 06/30/2014 01:02 PM, Paul Mackerras wrote: > >On Mon, Jun 30, 2014 at 12:52:29PM +0200, Hannes Reinecke wrote: > >>On 06/30/2014 12:30 PM, Paul Mackerras wrote: > >>>I have a machine on which 3.15 u

Re: Regression in 3.15 on POWER8 with multipath SCSI

On Mon, Jun 30, 2014 at 12:52:29PM +0200, Hannes Reinecke wrote: > On 06/30/2014 12:30 PM, Paul Mackerras wrote: > >I have a machine on which 3.15 usually fails to boot, and 3.14 boots > >every time. The machine is a POWER8 2-socket server with 20 cores > >(thus 160 CPUs)

<    1   2   3   4   5   6   7   8   9   10   >