[PATCH v3 3/5] rfi-flush: Always enable fallback flush on pseries

From: Michael Ellerman This ensures the fallback flush area is always allocated on pseries, so in case a LPAR is migrated from a patched to an unpatched system, it is possible to enable the fallback flush in the target system. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oli

[PATCH v3 4/5] rfi-flush: Differentiate enabled and patched flush types

Currently the rfi-flush messages print 'Using flush' for all enabled_flush_types, but that is not necessarily true -- as now the fallback flush is always enabled on pseries, but the fixup function overwrites its nop/branch slot with other flush types, if available. So, replace the 'Using flush'

[PATCH v3 5/5] rfi-flush: Call setup_rfi_flush() after LPM migration

From: Michael Ellerman We might have migrated to a machine that uses a different flush type, or doesn't need flushing at all. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira --- arch/powerpc/platforms/pseries/mobility.c | 3 +++ arch/powerpc/platforms/pseries/pseries

[TESTS] Create 'enabled_flush_types' boot option, and short-circuit LPM

fallback -> fallback: # dmesg -c | grep rfi-flush [0.00] rfi-flush (debug): enabled flush types: 0x0 [0.00] rfi-flush: fallback displacement flush available [0.00] rfi-flush: patched 8 locations (fallback displacement flush) # echo > /sys/kernel/mobilit

Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h

On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann wrote: > On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani > wrote: >> The file arch/arm64/kernel/process.c needs asm/compat.h also to be >> included directly since this is included conditionally from >> include/compat.h. This does seem to be typical

[PATCHv5 0/3] enable nr_cpus for powerpc

This topic has a very long history. It comes from Mahesh Salgaonkar For v3: https://patchwork.ozlabs.org/patch/834860/ I hope we can acquire it for "kexec -p" soon. V4->V5: improve the [1/3] implementation based on Benjamin's suggestion. Mahesh Salgaonkar (1): ppc64 boot: Wait for boot cpu

[PATCHv5 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt

For kexec -p, the boot cpu can be not the cpu0, this causes the problem to alloc paca[]. In theory, there is no requirement to assign cpu's logical id as its present seq by device tree. But we have something like cpu_first_thread_sibling(), which makes assumption on the mapping inside a core. Hence

[PATCHv5 2/3] powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus

For kexec -p, after boot_cpuid is mapping into the range of [0, threads_per_core), then if nr_cpus is small, we will have the bitmap [0,..., nr_cpus, ..., boot_cpuid, ...). This patch chooses cpus inside the range of [boot_cpuid - nr_cpus +1, ..., boot_cpuid] to be online. With this patch and the

[PATCHv5 3/3] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.

From: Mahesh Salgaonkar The kernel boot parameter 'nr_cpus=' allows one to specify number of possible cpus in the system. In the normal scenario the first cpu (cpu0) that shows up is the boot cpu and hence it gets covered under nr_cpus limit. But this assumption will be broken in kdump scenario

Re: [PATCH kernel] powerpc/npu: Do not try invalidating 32bit table when 64bit table is enabled

I must admit I haven't really looked at the iommu_table_group code in depth so don't fully understand it, but I was wondering why we don't hit this for NVLink1 as well? The error that Skiboot is printing is because the requested page size doesn't match expected so I guess there is a possibility th

Re: [PATCH] cxl: Perform NULL check for 'cxl_afu *' at various places in cxl

Thanks for reviewing this patch Fred, Frederic Barrat writes: > So we are calling functions with an invalid afu argument. We can verify > in the callees the value of the afu pointer, like you're doing here, but > why not tackle it at source and avoid calling the function in the first > place?

[RFC PATCH] powerpc/fadump: Reservationless firmware assisted dump

From: Mahesh Salgaonkar One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. On large systems with TeraBytes of memory, this reservation can be quite significant. In some cases, fadump fails if the memory reserved is in

<    1   2