Re: [PATCH] pseries/drmem: Check for zero filled ibm, dynamic-memory property.

Looks good to me. Boots without backtrace. qemu-system-ppc64 -enable-kvm -cpu POWER8 -m 4G -M pseries -nographic -vga none -kernel /tmp/vmlinux qemu-system-ppc64 --version QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.20) Tested-by: Daniel Black

Re: [PATCH] pseries/drmem: Check for zero filled ibm, dynamic-memory property.

On Thu, 2018-02-15 at 21:27 -0600, Nathan Fontenot wrote: > Some versions of QEMU will produce an ibm,dynamic-reconfiguration-memory > node with a ibm,dynamic-memory property that is zero-filled. This causes > the drmem code to oops trying to parse this property. > > The fix for this is to

[PATCH] pseries/drmem: Check for zero filled ibm, dynamic-memory property.

Some versions of QEMU will produce an ibm,dynamic-reconfiguration-memory node with a ibm,dynamic-memory property that is zero-filled. This causes the drmem code to oops trying to parse this property. The fix for this is to validate that the property does contain LMB entries before trying to parse

[PATCH v2 (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings

This is a new CPU feature advertising interface that is fine-grained, extensible, aware of privilege levels, and gives control of features to all levels of the stack (firmware, hypervisor, and OS). The design and binding specification is described in detail in doc/. Signed-off-by: Nicholas

Re: [PATCH] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate

On Wed, 14 Feb 2018, Alistair Popple wrote: > > > +struct mmio_atsd_reg { > > > + struct npu *npu; > > > + int reg; > > > +}; > > > + > > > > Is it just easier to move reg to inside of struct npu? > > I don't think so, struct npu is global to all npu contexts where as this is > specific to

Re: [PATCH v2] cxl: Check if PSL data-cache is available before issue flush request

On 16/02/18 02:49, Vaibhav Jain wrote: PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache. This is

[RFC 3/4] powerpc/hotplug/drcinfo: Fix hot-add CPU issues

This patch applies a common parse function for the ibm,drc-info property that can be modified by a callback function to the hot-add CPU code. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In addition, a bug in the

[RFC] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation

Add code to parse the new property 'ibm,thread-groups" when it is present. The content of this property explicitly defines the number of threads per core as well as the PowerPC 'threads_core_mask'. The design provides a common device-tree for both P9 normal core and P9 fused core systems. The

[RFC 3/3] postmigration/memory: Associativity & ibm, dynamic-memory-v2

postmigration/memory: Now apply changes to the associativity of memory blocks described by the 'ibm,dynamic-memory-v2' property regarding the topology of LPARS in Post Migration events. * Extend the previous work done for the 'ibm,associativity-lookup-array' to apply to either property

[RFC 2/3] postmigration/memory: Review assoc lookup array changes

postmigration/memory: In an LPAR migration scenario, the property "ibm,associativity-lookup-arrays" may change. In the event that a row of the array differs, locate all assigned memory blocks with that 'aa_index' and 're-add' them to the system memory block data structures. In the process of the

[RFC 1/3] hotplug/mobility: Apply assoc updates for Post Migration Topo

hotplug/mobility: Recognize more changes to the associativity of memory blocks described by the 'ibm,dynamic-memory' and 'cpu' properties when processing the topology of LPARS in Post Migration events. Previous efforts only recognized whether a memory block's assignment had changed in the

[RFC 0/3] powerpc/hotplug: Fix affinity assoc for LPAR migration

The migration of LPARs across Power systems affects many attributes including that of the associativity of memory blocks and CPUs. The patches in this set execute when a system is coming up fresh upon a migration target. They are intended to, * Recognize changes to the associativity of memory

Re: [PATCH] powerpc/eeh: Add conditional check on notify_resume

On 16/02/18 05:49, Bryant G. Ly wrote: From: "Juan J. Alvarez" EEH structure is not populated with function notify resume when running on systems that do not support it, i.e: BMC. Hence adding a conditional check for NULL for Seems to me that by "BMC" you really

[RFC 4/4] powerpc/hotplug/drcinfo: Improve code for ibm,drc-info device processing

This patch extends the use of a common parse function for the ibm,drc-info property that can be modified by a callback function to the hotplug device processing. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In

[RFC 2/4] powerpc/hotplug/drcinfo: Provide common parser for ibm,drc-info

This patch provides a common parse function for the ibm,drc-info property that can be modified by a callback function. The caller provides a pointer to the function and a pointer to their unique data, and the parser provides the current lmb set from the struct. The callback function may return

[RFC 1/4] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs

This patch fixes a memory parsing bug when using of_prop_next_u32 calls at the start of a structure. Depending upon the value of "cur" memory pointer argument to of_prop_next_u32, it will or it won't advance the value of the returned memory pointer by the size of one u32. This patch corrects the

[RFC 0/4] powerpc/drcinfo: Fix bugs 'ibm,drc-info' property

This patch set corrects some errors and omissions in the previous set of patches adding support for the "ibm,drc-info" property to powerpc systems. Unfortunately, some errors in the previous patch set break things in some of the DLPAR operations. In particular when attempting to hot-add a new

Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

On 02/15/2018 05:25 PM, Daniel Borkmann wrote: > On 02/13/2018 05:05 AM, Sandipan Das wrote: >> The imm field of a bpf_insn is a signed 32-bit integer. For >> JIT-ed bpf-to-bpf function calls, it stores the offset from >> __bpf_call_base to the start of the callee function. >> >> For some

[PATCH] powerpc/eeh: Add conditional check on notify_resume

From: "Juan J. Alvarez" EEH structure is not populated with function notify resume when running on systems that do not support it, i.e: BMC. Hence adding a conditional check for NULL for systems that don't add function notify_resume. Signed-off-by: Juan J. Alvarez

Re: [PATCH 0/3] perf trace powerpc: Remove libaudit dependency for syscalls

Em Mon, Jan 29, 2018 at 02:04:14PM +0530, Ravi Bangoria escreveu: > This is almost identical set of patches recently done for s390. > > With this, user can run perf trace without libaudit on powerpc > as well. Ex, > > $ make > ... libaudit: [ OFF ] > > $ ./perf trace ls Thanks,

Re: [PATCH 0/3] perf trace powerpc: Remove libaudit dependency for syscalls

Em Thu, Feb 15, 2018 at 10:43:36AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jan 29, 2018 at 02:04:14PM +0530, Ravi Bangoria escreveu: > > This is almost identical set of patches recently done for s390. > > > > With this, user can run perf trace without libaudit on powerpc > > as well.

Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

On 02/13/2018 05:05 AM, Sandipan Das wrote: > The imm field of a bpf_insn is a signed 32-bit integer. For > JIT-ed bpf-to-bpf function calls, it stores the offset from > __bpf_call_base to the start of the callee function. > > For some architectures, such as powerpc64, it was found that > this

[PATCH V2] cxl: Fix timebase synchronization status on P9

The PSL Timebase register is updated by the PSL to maintain the timebase. On P9, the Timebase value is only provided by the CAPP as received the last time a timebase request was performed. The timebase requests are initiated through the adapter configuration or application registers. The specific

[PATCH] cxl: Fix timebase synchronization status on P9

The PSL Timebase register is updated by the PSL to maintain the timebase. On P9, the Timebase value is only provided by the CAPP as received the last time a timebase request was performed. The timebase requests are initiated through the adapter configuration or application registers. The specific

[PATCH v2] cxl: Check if PSL data-cache is available before issue flush request

PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache. This is usually indicated in the kernel logs with

[PATCH] crypto: nx-842: Delete an error message for a failed memory allocation in nx842_pseries_init()

From: Markus Elfring Date: Wed, 14 Feb 2018 17:05:13 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH v2] powerpc/via-pmu: Fix section mismatch warning

On 14/02/2018 22:15, Mathieu Malaterre wrote: > Make the struct via_pmu_driver const to avoid following warning: > > WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the > variable via_pmu_driver to the function .init.text:pmu_init() > The variable via_pmu_driver references

Re: [PATCH] cxl: Check if PSL data-cache is available before issue flush request

Le 13/02/2018 à 12:10, Vaibhav Jain a écrit : PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache.

Re: [PATCH v2] cxl: Remove function write_timebase_ctrl_psl9() for PSL9

Le 15/02/2018 à 07:19, Vaibhav Jain a écrit : For PSL9 the contents of PSL_TB_CTLSTAT register have changed in PSL9 and all of the register is now readonly. Hence we don't need an sl_ops implementation for 'write_timebase_ctrl' for to populate this register for PSL9. Hence this patch removes