Re: [PATCH 1/2] powerpc: Batch up loads/stores on saving and restoring Altivec

On Thu, 10 Mar 2016 16:37:47 +1100 Cyril Bur wrote: > On Thu, 10 Mar 2016 10:01:07 +1100 > Michael Neuling wrote: > > > On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > > > > > Currently the assembly to save and restore Altivec registers boils

Re: [PATCH 1/2] ppc64le live patch: clear out storage location(s) in mini stack frame

On 10/03/16 04:28, Torsten Duwe wrote: > This can be applied on top of Petr Mladek's v4 rework of the ppc64le > live patching. Inspired by Balbir Singh's v5, information about the > callee's r2 is stored in a "reserved" 32 bit location in the caller's > stack frame, instead of 64 bits in the

Re: [RFC 2/9] mm/hugetlb: Add follow_huge_pgd function

On 03/09/2016 05:40 PM, Anshuman Khandual wrote: > This just adds 'follow_huge_pgd' function which is will be used > later in this series to make 'follow_page_mask' function aware > of PGD based huge page implementation. Hugh/Mel/Naoya/Andrew, Thoughts/inputs/suggestions ? Does this

Re: [RFC 3/9] mm/gup: Make follow_page_mask function PGD implementation aware

On 03/09/2016 05:40 PM, Anshuman Khandual wrote: > Currently the function 'follow_page_mask' does not take into account > PGD based huge page implementation. This change achieves that and > makes it complete. Hugh/Mel/Naoya/Andrew, Thoughts/inputs/suggestions ? Does this change look okay

Re: [RFC 1/9] mm/hugetlb: Make GENERAL_HUGETLB functions PGD implementation aware

On 03/09/2016 05:40 PM, Anshuman Khandual wrote: > Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc' > and 'huge_pte_offset' dont take into account huge page implementation > at the PGD level. With addition of PGD awareness into these functions, > more architectures like

Re: [PATCH kernel 8/9] KVM: PPC: Add in-kernel handling for VFIO

On 03/10/2016 04:18 PM, David Gibson wrote: On Wed, Mar 09, 2016 at 07:46:47PM +1100, Alexey Kardashevskiy wrote: On 03/08/2016 10:08 PM, David Gibson wrote: On Mon, Mar 07, 2016 at 02:41:16PM +1100, Alexey Kardashevskiy wrote: This allows the host kernel to handle H_PUT_TCE,

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

On 10/03/16 12:18, Ian Munsie wrote: On a related matter, we should send a patch to remove some of the leftover config options that were added to smooth the merging of cxlflash in the first place (CXL_KERNEL_API, CXL_EEH). I'm happy to do that after this series is merged. -- Andrew Donnellan

Re: [PATCH 0/3] powerpc/powernv: Cpuidle related cleanup

On Thu, 2016-03-10 at 16:15 +0530, Shreyas B Prabhu wrote: > Hi, > Any thoughts on this? Haven't had time to give it a proper review yet. Will try and get to it. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

[PATCH] T104xRDB: add tdm riser card node to device tree

Signed-off-by: Zhao Qiang --- arch/powerpc/boot/dts/fsl/t104xrdb.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi index 830ea48..be7bab6 100644 ---

Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame

On Thu, 2016-03-10 at 14:04 +0100, Torsten Duwe wrote: > On Thu, Mar 10, 2016 at 01:51:16PM +0100, Petr Mladek wrote: > > On Thu 2016-03-10 13:25:08, Petr Mladek wrote: > > > On Wed 2016-03-09 18:30:17, Torsten Duwe wrote: > > > > After the mini stack frame is no longer required for TOC storage,

Re: [2/2] Fix misleading comment for hard_irq_disable() in pmao_restore_workaround

On Fri, 2016-04-03 at 05:01:49 UTC, Madhavan Srinivasan wrote: > Current comment added in pmao_restore_workaround() for > hard_irq_disable is misleading. Comment should say to hard > "disable" interrupts instead of "enable" it. Patch to fix the typo. > > Signed-off-by: Madhavan Srinivasan

Re: [1/2] powerpc/perf: Remove PME_ prefix for power7 events

On Mon, 2016-11-01 at 22:55:25 UTC, Sukadev Bhattiprolu wrote: > We used the PME_ prefix earlier to avoid some macro/variable name > collisions. We have since changed the way we define/use the event > macros so we no longer need the prefix. > > By dropping the prefix, we keep the the event

Re: [1/2] powerpc/perf/hv-24x7: Fix usage with chip events

On Sat, 2016-30-01 at 03:07:10 UTC, Sukadev Bhattiprolu wrote: > >From 9b5848ce1834a4d82fc251022035d36d9e26b500 Mon Sep 17 00:00:00 2001 > From: Sukadev Bhattiprolu > Date: Sat, 23 Jan 2016 03:58:12 -0500 > Subject: [PATCH 1/2] powerpc/perf/hv-24x7: Fix usage with chip

Re: [1/2] powerpc/perf/hv-24x7: Display domain indices in sysfs

On Tue, 2016-16-02 at 23:24:27 UTC, Sukadev Bhattiprolu wrote: > >From aff5a822e873522b9a3f355f816547394b452a64 Mon Sep 17 00:00:00 2001 > From: Sukadev Bhattiprolu > Date: Tue, 16 Feb 2016 20:07:51 -0500 > Subject: [PATCH 1/2] powerpc/perf/hv-24x7: Display domain

Re: [PATCH kernel 3/9] KVM: PPC: Use preregistered memory API to access TCE list

On Thu, Mar 10, 2016 at 07:33:05PM +1100, Paul Mackerras wrote: > On Mon, Mar 07, 2016 at 05:00:14PM +1100, David Gibson wrote: > > On Mon, Mar 07, 2016 at 02:41:11PM +1100, Alexey Kardashevskiy wrote: > > > VFIO on sPAPR already implements guest memory pre-registration > > > when the entire guest

Re: [PATCH] powerpc/pci: Reuse PHB number on pci_controller add if available

On Fri, Mar 11, 2016 at 08:34:58AM +1100, Benjamin Herrenschmidt wrote: >On Thu, 2016-03-10 at 15:11 -0300, Guilherme G. Piccoli wrote: >> The domain/PHB field of PCI addresses has its value obtained from a >> global variable, incremented each time a new domain (represented by >> struct

Re: [PATCH kernel 9/9] KVM: PPC: VFIO device: support SPAPR TCE

On 03/10/2016 04:21 PM, David Gibson wrote: On Wed, Mar 09, 2016 at 08:20:12PM +1100, Alexey Kardashevskiy wrote: On 03/09/2016 04:45 PM, David Gibson wrote: On Mon, Mar 07, 2016 at 02:41:17PM +1100, Alexey Kardashevskiy wrote: sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap

Re: [PATCH] powerpc/pci: Reuse PHB number on pci_controller add if available

On Thu, 2016-03-10 at 15:11 -0300, Guilherme G. Piccoli wrote: > The domain/PHB field of PCI addresses has its value obtained from a > global variable, incremented each time a new domain (represented by > struct pci_controller) is added on the system. The domain addition > process happens during

Re: [PATCH] livepatch: Add some basic LivePatch documentation

On Wed, Mar 09, 2016 at 03:01:46PM +0100, Petr Mladek wrote: > LivePatch framework deserves some documentation, definitely. > This is an attempt to provide some basic info. I hope that > it will be useful for both LivePatch producers and also > potential developers of the framework itself. > >

[PATCH] Reuse PHB/domain number on PCI adresses when available

This patch changes the way PCI domain numbers are generated on powerpc. No functional changes were introduced. The reason for this modification is better explained on patch's commit message, but in short we currently increment a global variable at each new PHB discovered, and use this value as

[PATCH] powerpc/pci: Reuse PHB number on pci_controller add if available

The domain/PHB field of PCI addresses has its value obtained from a global variable, incremented each time a new domain (represented by struct pci_controller) is added on the system. The domain addition process happens during boot or due to PCI device hotplug. As recent kernels are using

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Ian Munsie writes: > No, the kconfig option is there so that cxlflash can add support for > this and not have to worry about breaking any builds if their code is > merged into the scsi tree that doesn't have our code yet. > > There is nothing optional about this within our

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Michael Neuling writes: > These are here to enable the feature in other drivers. So the cxlflash > (or whoever) can put their code in via the linux-scsi tree but that new > piece is only enabled when CXL_AFU_DRIVER_OPS is present (ie. when > merged upstream). But if it's

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Frederic Barrat writes: > Hi Vaibhav, > > Le 09/03/2016 15:37, Vaibhav Jain a écrit : > >> I would propose these two apis. >> >> /* >> * fetches an event from the driver event queue. NULL means that queue >> * is empty. Can sleep if needed. The memory for cxl_event

Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame

On Thu, Mar 10, 2016 at 01:51:16PM +0100, Petr Mladek wrote: > On Thu 2016-03-10 13:25:08, Petr Mladek wrote: > > On Wed 2016-03-09 18:30:17, Torsten Duwe wrote: > > > After the mini stack frame is no longer required for TOC storage, it can > > > be eliminated iff the functionality of

Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame

On Thu, 10 Mar 2016, Petr Mladek wrote: > BTW: How is this solved in kretprobes? Or is it easier there? Is that really a problem? With kretprobes you're never performing the module->core->module transition in "one" redirection, right? The 'kretprobe_trampoline' is a global symbol, and hence

Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame

On Thu 2016-03-10 13:25:08, Petr Mladek wrote: > On Wed 2016-03-09 18:30:17, Torsten Duwe wrote: > > After the mini stack frame is no longer required for TOC storage, it can > > be eliminated iff the functionality of klp_return_helper, which required > > a stack frame for the extra return address

Re: [PATCH 2/2] ppc64le live patch: get rid of mini stack frame

On Wed 2016-03-09 18:30:17, Torsten Duwe wrote: > After the mini stack frame is no longer required for TOC storage, it can > be eliminated iff the functionality of klp_return_helper, which required > a stack frame for the extra return address previously, is carried out > by the replacement

RE: Freescale P5020 cpu will be kvm-pr?

Hi Scott, sorry for late reply in this last few days i become another time father . In any way for better explain the issue i attached my dmesg log probably will make understand better than my poor english Thanks for your time Luigi Burdo AmigaOne X5000 beta tester From:

Re: [PATCH 0/3] powerpc/powernv: Cpuidle related cleanup

Hi, Any thoughts on this? On 02/29/2016 05:52 PM, Shreyas B. Prabhu wrote: > These patches are purely code movement and cleanup. > There is no functionality change. > > Note, there are multiple style error reported for patch 1 and 2. > I think this is because checkpatch script mistakes the

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 03:26:21PM -0600, Scott Wood wrote: > On Wed, 2016-03-09 at 11:28 +0100, Gabriel Paubert wrote: > > On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > > > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > > > The mtmsr() function hangs

Re: [PATCH] livepatch: Add some basic LivePatch documentation

On Wed, 9 Mar 2016, Petr Mladek wrote: > LivePatch framework deserves some documentation, definitely. > This is an attempt to provide some basic info. I hope that > it will be useful for both LivePatch producers and also > potential developers of the framework itself. Thanks for starting the

Re: [PATCH kernel 4/9] powerpc/powernv/iommu: Add real mode version of xchg()

On Mon, Mar 07, 2016 at 02:41:12PM +1100, Alexey Kardashevskiy wrote: > In real mode, TCE tables are invalidated using different > cache-inhibited store instructions which is different from > the virtual mode. I suggest "In real mode, TCE tables are invalidated using special cache-inhibited store

Re: [PATCH kernel 4/9] powerpc/powernv/iommu: Add real mode version of xchg()

On Mon, Mar 07, 2016 at 02:41:12PM +1100, Alexey Kardashevskiy wrote: > In real mode, TCE tables are invalidated using different > cache-inhibited store instructions which is different from > the virtual mode. > > This defines and implements exchange_rm() callback. This does not > define

Re: [PATCH kernel 3/9] KVM: PPC: Use preregistered memory API to access TCE list

On Mon, Mar 07, 2016 at 05:00:14PM +1100, David Gibson wrote: > On Mon, Mar 07, 2016 at 02:41:11PM +1100, Alexey Kardashevskiy wrote: > > VFIO on sPAPR already implements guest memory pre-registration > > when the entire guest RAM gets pinned. This can be used to translate > > the physical address