[PATCH 15/15] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

Using single PE BARs to map an SR-IOV BAR is really a choice about what strategy to use when mapping a BAR. It doesn't make much sense for this to be a global setting since a device might have one large BAR which needs to be mapped with single PE windows and another smaller BAR that can be mapped

[PATCH 14/15] powerpc/powernv/sriov: Refactor M64 BAR setup

Split up the logic so that we have one branch that handles setting up a segmented window and another that handles setting up single PE windows for each VF. Signed-off-by: Oliver O'Halloran --- This patch could be folded into the previous one. I've kept it seperate mainly because the diff is

[PATCH 13/15] powerpc/powernv/sriov: Move M64 BAR allocation into a helper

I want to refactor the loop this code is currently inside of. Hoist it on out. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++ 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c

[PATCH 12/15] powerpc/powernv/sriov: De-indent setup and teardown

Remove the IODA2 PHB checks. We already assume IODA2 in several places so there's not much point in wrapping most of the setup and teardown process in an if block. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-sriov.c | 86 -- 1 file changed, 49

[PATCH 11/15] powerpc/powernv/sriov: Drop iov->pe_num_map[]

Currently the iov->pe_num_map[] does one of two things depending on whether single PE mode is being used or not. When it is, this contains an array which maps a vf_index to the corresponding PE number. When single PE mode is not being used this contains a scalar which is the base PE for the set of

[PATCH 10/15] powerpc/powernv/pci: Refactor pnv_ioda_alloc_pe()

Rework the PE allocation logic to allow allocating blocks of PEs rather than individually. We'll use this to allocate contigious blocks of PEs for the SR-IOVs. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 41 ++-

[PATCH 09/15] powerpc/powernv/sriov: Factor out M64 BAR setup

The sequence required to use the single PE BAR mode is kinda janky and requires a little explanation. The API was designed with P7-IOC style windows where the setup process is something like: 1. Configure the window start / end address 2. Enable the window 3. Map the segments of each window to

[PATCH 08/15] powerpc/powernv/sriov: Simplify used window tracking

No need for the multi-dimensional arrays, just use a bitmap. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-sriov.c | 48 +++--- arch/powerpc/platforms/powernv/pci.h | 7 +++- 2 files changed, 20 insertions(+), 35 deletions(-) diff --git

[PATCH 07/15] powerpc/powernv/sriov: Rename truncate_iov

This prevents SR-IOV being used by making the SR-IOV BAR resources unallocatable. Rename it to reflect what it actually does. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-sriov.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git

[PATCH 05/15] powerpc/powernv/sriov: Move SR-IOV into a seperate file

pci-ioda.c is getting a bit unwieldly due to the amount of stuff jammed in there. The SR-IOV support can be extracted easily enough and is mostly standalone, so move it into a seperate file. This patch also moves the PowerNV SR-IOV specific fields from pci_dn and moves them into a platform

[PATCH 06/15] powerpc/powernv/sriov: Explain how SR-IOV works on PowerNV

SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea how anyone is supposed to know how it works except through a lot of stuffering. Write up some docs about the overall story to help out the next sucker^Wperson who needs to tinker with it. Signed-off-by: Oliver O'Halloran ---

[PATCH 04/15] powerpc/powernv/pci: Initialise M64 for IODA1 as a 1-1 window

We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping, similar to PHB3. Currently the actual mapping of segments occurs in pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and drop the IODA1 specific code paths in the PE setup / teardown. Signed-off-by: Oliver

[PATCH 03/15] powerpc/powernv/pci: Add explicit tracking of the DMA setup state

There's an optimisation in the PE setup which skips performing DMA setup for a PE if we only have bridges in a PE. The assumption being that only "real" devices will DMA to system memory, which is probably fair. However, if we start off with only bridge devices in a PE then add a non-bridge device

[PATCH 02/15] powerpc/powernv/pci: Always tear down DMA windows on PE release

Currently we have these two functions: pnv_pci_ioda2_release_dma_pe(), and pnv_pci_ioda2_release_pe_dma() The first is used when tearing down VF PEs and the other is used for normal devices. There's very little difference between the two though. The latter (non-VF) will skip a

[PATCH 01/15] powernv/pci: Add pci_bus_to_pnvhb() helper

Add a helper to go from a pci_bus structure to the pnv_phb that hosts that bus. There's a lot of instances of the following pattern: struct pci_controller *hose = pci_bus_to_host(pdev->bus); struct pnv_phb *phb = hose->private_data; Without any other uses of the pci_controller

PowerNV PCI & SR-IOV cleanups

Finally bit the bullet and learned how all the MMIO->PE mapping setup actually works. As a side effect I found a bunch of oddities in how PowerNV SR-IOV support is implemented. This series mostly sorts that out with a few more generic cleanups along the way. This is largely prep work for

[PATCH v2 1/3] powerpc/powernv/idle: Exclude mfspr on HID1, 4, 5 on P9 and above

POWER9 onwards the support for the registers HID1, HID4, HID5 has been receded. Although mfspr on the above registers worked in Power9, In Power10 simulator is unrecognized. Moving their assignment under the check for machines lower than Power9 Signed-off-by: Pratik Rajesh Sampat Reviewed-by:

[PATCH v2 3/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

Replace the variable name from using "pnv_first_spr_loss_level" to "pnv_first_fullstate_loss_level". As pnv_first_spr_loss_level is supposed to be the earliest state that has OPAL_PM_LOSE_FULL_CONTEXT set, however as shallow states too loose SPR values, render an incorrect terminology.

[PATCH v2 2/3] powerpc/powernv/idle: save-restore DAWR0, DAWRX0 for P10

Additional registers DAWR0, DAWRX0 may be lost on Power 10 for stop levels < 4. Therefore save the values of these SPRs before entering a "stop" state and restore their values on wakeup. Signed-off-by: Pratik Rajesh Sampat --- arch/powerpc/platforms/powernv/idle.c | 10 ++ 1 file

[PATCH v2 0/3] Power10 basic energy management

Changelog v1 --> v2: 1. Save-restore DAWR and DAWRX unconditionally as they are lost in shallow idle states too 2. Rename pnv_first_spr_loss_level to pnv_first_fullstate_loss_level to correct naming terminology Pratik Rajesh Sampat (3): powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and

[RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

On big systems, the mm refcount can become highly contented when doing a lot of context switching with threaded applications (particularly switching between the idle thread and an application thread). Abandoning lazy tlb slows switching down quite a bit in the important user->idle->user cases, so

[RFC PATCH 6/7] lazy tlb: allow lazy tlb mm switching to be configurable

NOMMU systems could easily go without this and save a bit of code and the mm refcounting, because their mm switch is a no-op. I haven't flipped them over because haven't audited all arch code to convert over to using the _lazy_tlb refcounting. Signed-off-by: Nicholas Piggin --- arch/Kconfig

[RFC PATCH 5/7] lazy tlb: introduce lazy mm refcount helper functions

Add explicit _lazy_tlb annotated functions for lazy mm refcounting. This makes things a bit more explicit, and allows explicit refcounting to be removed if it is not used. Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/smp.c| 2 +- arch/powerpc/mm/book3s64/radix_tlb.c | 4

[RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

And get rid of the generic sync_core_before_usermode facility. This helper is the wrong way around I think. The idea that membarrier state requires a core sync before returning to user is the easy one that does not need hiding behind membarrier calls. The gap in core synchronization due to x86's

[RFC PATCH 3/7] mm: introduce exit_lazy_tlb

Signed-off-by: Nicholas Piggin --- fs/exec.c | 5 +++-- include/asm-generic/mmu_context.h | 20 kernel/kthread.c | 1 + kernel/sched/core.c | 2 ++ 4 files changed, 26 insertions(+), 2 deletions(-) diff --git

[RFC PATCH 2/7] arch: use asm-generic mmu context for no-op implementations

This patch bunches all architectures together. If the general idea is accepted I will split them individually. Some architectures can go further e.g., with consolidating switch_mm and activate_mm but I only did the more obvious ones. --- arch/alpha/include/asm/mmu_context.h | 12 ++---

[RFC PATCH 1/7] asm-generic: add generic MMU versions of mmu context functions

Many of these are no-ops on many architectures, so extend mmu_context.h to cover MMU and NOMMU, and split the NOMMU bits out to nommu_context.h Cc: Arnd Bergmann Cc: Remis Lima Baima Signed-off-by: Nicholas Piggin --- arch/microblaze/include/asm/mmu_context.h | 2 +-

[RFC PATCH 0/7] mmu context cleanup, lazy tlb cleanup,

This blew up a bit bigger than I thought, so I'd like to get some comments as to whether people agree with the direction it's going. The patches aren't cleanly split out by arch, but as it is now it's probably easier to get a quick overview of the changes at a glance anyway. So there's a few

Re: [RFC][PATCH] avoid refcounting the lazy tlb mm struct

Hi Nick, > On big systems, the mm refcount can become highly contented when doing > a lot of context switching with threaded applications (particularly > switching between the idle thread and an application thread). > > Not doing lazy tlb at all slows switching down quite a bit, so I > wonder if

RE: [PATCH 1/2] powerpc/vas: Report proper error for address translation failure

copied verbatim from P9 DD2 Nest Accelerators Workbook Version 3.2 Table 4-36. CSB Non-zero CC Reported Error Types CC=5, Error Type: Translation, Comment: Unused, defined by RFC02130 (footnote: DMA controller uses this CC internally in translation fault handling. Do not reuse for other

RE: [PATCH 1/2] powerpc/vas: Report proper error for address translation failure

"Linuxppc-dev" wrote on 07/09/2020 04:22:10 AM: > From: Michael Ellerman > To: Haren Myneni > Cc: tuli...@br.ibm.com, ab...@us.ibm.com, linuxppc- > d...@lists.ozlabs.org, rzin...@linux.ibm.com > Date: 07/09/2020 04:21 AM > Subject: [EXTERNAL] Re: [PATCH 1/2] powerpc/vas: Report proper error

[PATCH v5] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime

APPRAISE_BOOTPARAM has been marked as dependent on !ARCH_POLICY in compile time, enforcing the appraisal whenever the kernel had the arch policy option enabled. However it breaks systems where the option is set but the system didn't boot in a "secure boot" platform. In this scenario, anytime an

Re: [PATCH 2/2] PCI/AER: Log correctable errors as warning, not error

On Tue, Jul 07, 2020 at 07:14:01PM -0500, Bjorn Helgaas wrote: > From: Matt Jolly > > PCIe correctable errors are recovered by hardware with no need for software > intervention (PCIe r5.0, sec 6.2.2.1). > > Reduce the log level of correctable errors from KERN_ERR to KERN_WARNING. > > The bug

Re: /sys/kernel/debug/kmemleak empty despite kmemleak reports

Dear Catalin, Am 09.07.20 um 19:57 schrieb Catalin Marinas: On Thu, Jul 09, 2020 at 04:37:10PM +0200, Paul Menzel wrote: Despite Linux 5.8-rc4 reporting memory leaks on the IBM POWER 8 S822LC, the file does not contain more information. $ dmesg […] > [48662.953323] perf: interrupt took too

Re: Failure to build librseq on ppc

- On Jul 9, 2020, at 4:46 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: > On Thu, Jul 09, 2020 at 01:56:19PM -0400, Mathieu Desnoyers wrote: >> > Just to make sure I understand your recommendation. So rather than >> > hard coding r17 as the temporary registers, we could explicitly

Re: Failure to build librseq on ppc

On Thu, Jul 09, 2020 at 01:56:19PM -0400, Mathieu Desnoyers wrote: > > Just to make sure I understand your recommendation. So rather than > > hard coding r17 as the temporary registers, we could explicitly > > declare the temporary register as a C variable, pass it as an > > input operand to the

Re: Failure to build librseq on ppc

On Thu, Jul 09, 2020 at 01:42:56PM -0400, Mathieu Desnoyers wrote: > > That works fine then, for a testcase. Using r17 is not a great idea for > > performance (it increases the active register footprint, and causes more > > registers to be saved in the prologue of the functions, esp. on older > >

Re: [PATCH 11/20] Documentation: leds/ledtrig-transient: eliminate duplicated word

On 7/7/20 8:04 PM, Randy Dunlap wrote: Drop the doubled word "for". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jacek Anaszewski Cc: Pavel Machek Cc: Dan Murphy Cc: linux-l...@vger.kernel.org --- Documentation/leds/ledtrig-transient.rst |2 +- 1

Re: /sys/kernel/debug/kmemleak empty despite kmemleak reports

On Thu, Jul 09, 2020 at 04:37:10PM +0200, Paul Menzel wrote: > Despite Linux 5.8-rc4 reporting memory leaks on the IBM POWER 8 S822LC, the > file does not contain more information. > > > $ dmesg > > […] > [48662.953323] perf: interrupt took too long (2570 > 2500), > > lowering >

Re: Failure to build librseq on ppc

- On Jul 9, 2020, at 1:42 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Jul 9, 2020, at 1:37 PM, Segher Boessenkool > seg...@kernel.crashing.org > wrote: > >> On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote: >>> > What protects r17 *after* this

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

https://bugzilla.kernel.org/show_bug.cgi?id=208197 --- Comment #9 from Erhard F. (erhar...@mailbox.org) --- (In reply to Michael Ellerman from comment #7) > I couldn't really make sense of your bisect log, it doesn't have any > good/bad commits in it. > > Can you attach the output of "git bisect

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

https://bugzilla.kernel.org/show_bug.cgi?id=208197 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #290097|0 |1 is obsolete|

Re: Failure to build librseq on ppc

- On Jul 9, 2020, at 1:37 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: > On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote: >> > What protects r17 *after* this asm statement? >> >> As discussed in the other leg of the thread (with the code example), >> r17 is in

Re: Failure to build librseq on ppc

On Thu, Jul 09, 2020 at 09:43:47AM -0400, Mathieu Desnoyers wrote: > > What protects r17 *after* this asm statement? > > As discussed in the other leg of the thread (with the code example), > r17 is in the clobber list of all asm statements using this macro, and > is used as a temporary register

Re: Failure to build librseq on ppc

On Thu, Jul 09, 2020 at 09:33:18AM -0400, Mathieu Desnoyers wrote: > > The way this all uses r17 will likely not work reliably. > > r17 is only used as a temporary register within the inline assembler, and it > is > in the clobber list. In which scenario would it not work reliably ? This isn't

[PATCH v2] powerpc/pseries: Avoid using addr_to_pfn in realmode

When an UE or memory error exception is encountered the MCE handler tries to find the pfn using addr_to_pfn() which takes effective address as an argument, later pfn is used to poison the page where memory error occurred, recent rework in this area made addr_to_pfn to run in realmode, which can be

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

On 7/9/20 6:53 AM, Michael Ellerman wrote: Nicholas Piggin writes: Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/paravirt.h | 28 arch/powerpc/include/asm/qspinlock.h | 66 +++ arch/powerpc/include/asm/qspinlock_paravirt.h | 7 ++

Re: [PATCH 10/20] Documentation: kbuild/kconfig-language: eliminate duplicated word

On Wed, Jul 8, 2020 at 3:06 AM Randy Dunlap wrote: > > Drop the doubled word "the". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Masahiro Yamada I guess this series will go in via the doc sub-system. If so, please feel free to add: Acked-by:

/sys/kernel/debug/kmemleak empty despite kmemleak reports

Dear Linux folks, Despite Linux 5.8-rc4 reporting memory leaks on the IBM POWER 8 S822LC, the file does not contain more information. $ dmesg […] > [48662.953323] perf: interrupt took too long (2570 > 2500), lowering kernel.perf_event_max_sample_rate to 77750 [48854.810636] perf:

Re: [PATCH v2 2/2] papr/scm: Add bad memory ranges to nvdimm bad ranges

Le 09/07/2020 à 15:51, Santosh Sivaraj a écrit : Subscribe to the MCE notification and add the physical address which generated a memory error to nvdimm bad range. Reviewed-by: Mahesh Salgaonkar Signed-off-by: Santosh Sivaraj Reviewed-by: Christophe Leroy ---

Re: [PATCH v2 1/2] powerpc/mce: Add MCE notification chain

Le 09/07/2020 à 15:51, Santosh Sivaraj a écrit : Introduce notification chain which lets us know about uncorrected memory errors(UE). This would help prospective users in pmem or nvdimm subsystem to track bad blocks for better handling of persistent memory allocations. Signed-off-by: Santosh

[PATCH v2 2/2] papr/scm: Add bad memory ranges to nvdimm bad ranges

Subscribe to the MCE notification and add the physical address which generated a memory error to nvdimm bad range. Reviewed-by: Mahesh Salgaonkar Signed-off-by: Santosh Sivaraj --- arch/powerpc/platforms/pseries/papr_scm.c | 96 ++- 1 file changed, 95 insertions(+), 1

[PATCH v2 1/2] powerpc/mce: Add MCE notification chain

Introduce notification chain which lets us know about uncorrected memory errors(UE). This would help prospective users in pmem or nvdimm subsystem to track bad blocks for better handling of persistent memory allocations. Signed-off-by: Santosh Sivaraj Signed-off-by: Ganesh Goudar ---

Re: Failure to build librseq on ppc

- On Jul 8, 2020, at 8:18 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: > On Wed, Jul 08, 2020 at 08:01:23PM -0400, Mathieu Desnoyers wrote: >> > > #define RSEQ_ASM_OP_CMPEQ(var, expect, label) >> > > \ >> > > LOAD_WORD "%%r17, %[" __rseq_str(var) "]\n\t"

Re: Failure to build librseq on ppc

- On Jul 8, 2020, at 8:10 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: > Hi! > > On Wed, Jul 08, 2020 at 10:00:01AM -0400, Mathieu Desnoyers wrote: [...] > >> -#define STORE_WORD "std " >> -#define LOAD_WORD "ld " >> -#define LOADX_WORD "ldx " >> +#define

[PATCH v3 4/4] powerpc/mm/radix: Create separate mappings for hot-plugged memory

To enable memory unplug without splitting kernel page table mapping, we force the max mapping size to the LMB size. LMB size is the unit in which hypervisor will do memory add/remove operation. Pseries systems supports max LMB size of 256MB. Hence on pseries, we now end up mapping memory with 2M

[PATCH v3 3/4] powerpc/mm/radix: Remove split_kernel_mapping()

From: Bharata B Rao We split the page table mapping on memory unplug if the linear range was mapped with huge page mapping (for ex: 1G) The page table splitting code has a few issues: 1. Recursive locking Memory unplug path takes cpu_hotplug_lock and calls stop_machine()

[PATCH v3 2/4] powerpc/mm/radix: Free PUD table when freeing pagetable

From: Bharata B Rao remove_pagetable() isn't freeing PUD table. This causes memory leak during memory unplug. Fix this. Fixes: 4b5d62ca17a1 ("powerpc/mm: add radix__remove_section_mapping()") Signed-off-by: Bharata B Rao Signed-off-by: Aneesh Kumar K.V ---

[PATCH v3 1/4] powerpc/mm/radix: Fix PTE/PMD fragment count for early page table mappings

We can hit the following BUG_ON during memory unplug: kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:342! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries NIP [c0093308] pmd_fragment_free+0x48/0xc0 LR [c147bfec]

[PATCH v3 0/4] powerpc/mm/radix: Memory unplug fixes

This is the next version of the fixes for memory unplug on radix. The issues and the fix are described in the actual patches. Changes from v2: - Address review feedback Changes from v1: - Added back patch to drop split_kernel_mapping - Most of the split_kernel_mapping related issues are now

[PATCH] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_DAWR_ARCH_31

PPC_DEBUG_FEATURE_DATA_BP_DAWR_ARCH_31 can be used to determine whether we are running on an ISA 3.1 compliant machine. Which is needed to determine DAR behaviour, 512 byte boundary limit etc. This was requested by Pedro Miraglia Franco de Carvalho for extending watchpoint features in gdb. Note

RE: [PATCH 14/20] Documentation: misc/xilinx_sdfec: eliminate duplicated word

> -Original Message- > From: Randy Dunlap > Sent: Tuesday 7 July 2020 19:04 > To: linux-ker...@vger.kernel.org > Cc: Randy Dunlap ; Jonathan Corbet ; > linux-...@vger.kernel.org; linux- > m...@vger.kernel.org; Mike Rapoport ; Jens Axboe > ; linux-bl...@vger.kernel.org; Jason > Wessel

Re: [PATCH v2 04/10] powerpc/perf: Add power10_feat to dt_cpu_ftrs

> On 08-Jul-2020, at 4:45 PM, Michael Ellerman wrote: > > Athira Rajeev > writes: >> From: Madhavan Srinivasan >> >> Add power10 feature function to dt_cpu_ftrs.c along >> with a power10 specific init() to initialize pmu sprs. >> >> Signed-off-by:

Re: [PATCH 2/2] powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10

On 09/07/20 2:39 pm, Gautham R Shenoy wrote: On Fri, Jul 03, 2020 at 06:16:40PM +0530, Pratik Rajesh Sampat wrote: Additional registers DAWR0, DAWRX0 may be lost on Power 10 for stop levels < 4. Adding Ravi Bangoria to the cc. Therefore save the values of these SPRs before entering a

Re: [PATCH 1/2] powerpc/vas: Report proper error for address translation failure

Haren Myneni writes: > DMA controller uses CC=5 internally for translation fault handling. So > OS should be using CC=250 and should report this error to the user space > when NX encounters address translation failure on the request buffer. That doesn't really explain *why* the OS must use

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory.

Re: [PATCH 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

Laurent Dufour writes: > Le 08/07/2020 à 13:25, Bharata B Rao a écrit : >> On Fri, Jul 03, 2020 at 05:59:14PM +0200, Laurent Dufour wrote: >>> When a secure memslot is dropped, all the pages backed in the secure device >>> (aka really backed by secure memory by the Ultravisor) should be paged out

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

On Thu, Jul 09, 2020 at 08:53:16PM +1000, Michael Ellerman wrote: > Nicholas Piggin writes: > > > Signed-off-by: Nicholas Piggin > > --- > > arch/powerpc/include/asm/paravirt.h | 28 > > arch/powerpc/include/asm/qspinlock.h | 66 +++ > >

Re: [PATCH 2/2] powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10

On Fri, Jul 03, 2020 at 06:16:40PM +0530, Pratik Rajesh Sampat wrote: > Additional registers DAWR0, DAWRX0 may be lost on Power 10 for > stop levels < 4. Adding Ravi Bangoria to the cc. > Therefore save the values of these SPRs before entering a "stop" > state and restore their values on

Re: [PATCH 1/2] powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above

On Fri, Jul 03, 2020 at 06:16:39PM +0530, Pratik Rajesh Sampat wrote: > POWER9 onwards the support for the registers HID1, HID4, HID5 has been > receded. > Although mfspr on the above registers worked in Power9, In Power10 > simulator is unrecognized. Moving their assignment under the > check for

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

Nicholas Piggin writes: > Signed-off-by: Nicholas Piggin > --- > arch/powerpc/include/asm/paravirt.h | 28 > arch/powerpc/include/asm/qspinlock.h | 66 +++ > arch/powerpc/include/asm/qspinlock_paravirt.h | 7 ++ >

Re: [PATCH v3 4/6] powerpc/64s: implement queued spinlocks and rwlocks

On Thu, Jul 09, 2020 at 08:20:25PM +1000, Michael Ellerman wrote: > Nicholas Piggin writes: > > These have shown significantly improved performance and fairness when > > spinlock contention is moderate to high on very large systems. > > > > [ Numbers hopefully forthcoming after more testing, but

Re: [PATCH] powerpc: select ARCH_HAS_MEMBARRIER_SYNC_CORE

Excerpts from Mathieu Desnoyers's message of July 9, 2020 12:12 am: > - On Jul 8, 2020, at 1:17 AM, Nicholas Piggin npig...@gmail.com wrote: > >> Excerpts from Mathieu Desnoyers's message of July 7, 2020 9:25 pm: >>> - On Jul 7, 2020, at 1:50 AM, Nicholas Piggin npig...@gmail.com wrote:

Re: [PATCH v2 2/3] powerpc/64s: remove PROT_SAO support

Excerpts from Paul Mackerras's message of July 9, 2020 2:34 pm: > On Fri, Jul 03, 2020 at 11:19:57AM +1000, Nicholas Piggin wrote: >> ISA v3.1 does not support the SAO storage control attribute required to >> implement PROT_SAO. PROT_SAO was used by specialised system software >> (Lx86) that has

Re: [PATCH v3 4/6] powerpc/64s: implement queued spinlocks and rwlocks

Nicholas Piggin writes: > These have shown significantly improved performance and fairness when > spinlock contention is moderate to high on very large systems. > > [ Numbers hopefully forthcoming after more testing, but initial >results look good ] Would be good to have something here,

Re: [PATCH v3 3/6] powerpc: move spinlock implementation to simple_spinlock

Nicholas Piggin writes: > To prepare for queued spinlocks. This is a simple rename except to update > preprocessor guard name and a file reference. > > Signed-off-by: Nicholas Piggin > --- > arch/powerpc/include/asm/simple_spinlock.h| 292 ++ >

Re: [PATCH v3 2/6] powerpc/pseries: move some PAPR paravirt functions to their own file

Nicholas Piggin writes: > Little bit of changelog would be nice :D > Signed-off-by: Nicholas Piggin > --- > arch/powerpc/include/asm/paravirt.h | 61 + > arch/powerpc/include/asm/spinlock.h | 24 +--- > arch/powerpc/lib/locks.c| 12 +++--- > 3

Re: [RFC PATCH v0 2/2] KVM: PPC: Book3S HV: Use H_RPT_INVALIDATE in nested KVM

On Thu, Jul 09, 2020 at 02:38:51PM +0530, Bharata B Rao wrote: > On Thu, Jul 09, 2020 at 03:18:03PM +1000, Paul Mackerras wrote: > > On Fri, Jul 03, 2020 at 04:14:20PM +0530, Bharata B Rao wrote: > > > In the nested KVM case, replace H_TLB_INVALIDATE by the new hcall > > > H_RPT_INVALIDATE if

Re: [PATCH v3 1/6] powerpc/powernv: must include hvcall.h to get PAPR defines

Nicholas Piggin writes: > An include goes away in future patches which breaks compilation > without this. > > Signed-off-by: Nicholas Piggin > --- > arch/powerpc/platforms/powernv/pci-ioda-tce.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH RESEND 1/2] powerpc/mce: Add MCE notification chain

Christophe Leroy writes: > Le 09/07/2020 à 09:56, Santosh Sivaraj a écrit : >> Introduce notification chain which lets know about uncorrected memory >> errors(UE). This would help prospective users in pmem or nvdimm subsystem >> to track bad blocks for better handling of persistent memory

Re: [PATCH RESEND 2/2] papr/scm: Add bad memory ranges to nvdimm bad ranges

Christophe Leroy writes: > Le 09/07/2020 à 09:56, Santosh Sivaraj a écrit : >> Subscribe to the MCE notification and add the physical address which >> generated a memory error to nvdimm bad range. >> >> Reviewed-by: Mahesh Salgaonkar >> Signed-off-by: Santosh Sivaraj >> --- >>

Re: [RFC PATCH v0 2/2] KVM: PPC: Book3S HV: Use H_RPT_INVALIDATE in nested KVM

On Thu, Jul 09, 2020 at 03:18:03PM +1000, Paul Mackerras wrote: > On Fri, Jul 03, 2020 at 04:14:20PM +0530, Bharata B Rao wrote: > > In the nested KVM case, replace H_TLB_INVALIDATE by the new hcall > > H_RPT_INVALIDATE if available. The availability of this hcall > > is determined from

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

On Wed, Jul 08, 2020 at 07:54:34PM -0400, Waiman Long wrote: > On 7/8/20 4:41 AM, Peter Zijlstra wrote: > > On Tue, Jul 07, 2020 at 03:57:06PM +1000, Nicholas Piggin wrote: > > > Yes, powerpc could certainly get more performance out of the slow > > > paths, and then there are a few parameters to

Re: [PATCH RESEND 2/2] papr/scm: Add bad memory ranges to nvdimm bad ranges

Le 09/07/2020 à 09:56, Santosh Sivaraj a écrit : Subscribe to the MCE notification and add the physical address which generated a memory error to nvdimm bad range. Reviewed-by: Mahesh Salgaonkar Signed-off-by: Santosh Sivaraj --- arch/powerpc/platforms/pseries/papr_scm.c | 98

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

On Thu, Jul 9, 2020 at 1:05 PM Palmer Dabbelt wrote: > > On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: > > This is a preparatory patch for relocatable kernel. > > > > The kernel used to be linked at PAGE_OFFSET address and used to be loaded > > physically at the beginning of the

Re: [PATCH RESEND 1/2] powerpc/mce: Add MCE notification chain

Le 09/07/2020 à 09:56, Santosh Sivaraj a écrit : Introduce notification chain which lets know about uncorrected memory errors(UE). This would help prospective users in pmem or nvdimm subsystem to track bad blocks for better handling of persistent memory allocations. Signed-off-by: Santosh S

[PATCH RESEND 2/2] papr/scm: Add bad memory ranges to nvdimm bad ranges

Subscribe to the MCE notification and add the physical address which generated a memory error to nvdimm bad range. Reviewed-by: Mahesh Salgaonkar Signed-off-by: Santosh Sivaraj --- arch/powerpc/platforms/pseries/papr_scm.c | 98 ++- 1 file changed, 97 insertions(+), 1

[PATCH RESEND 1/2] powerpc/mce: Add MCE notification chain

Introduce notification chain which lets know about uncorrected memory errors(UE). This would help prospective users in pmem or nvdimm subsystem to track bad blocks for better handling of persistent memory allocations. Signed-off-by: Santosh S Signed-off-by: Ganesh Goudar ---

Re: [PATCH v3 1/4] iomap: Constify ioreadX() iomem argument (as in generic implementation)

On Thu, Jul 09, 2020 at 09:28:34AM +0200, Krzysztof Kozlowski wrote: > The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On > some architectures void *__iomem address argument is a pointer to const, > on some not. > > Implementations of ioreadX() do not modify the memory under

[PATCH v3 4/4] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among

[PATCH v3 3/4] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among

[PATCH v3 2/4] rtl818x: Constify ioreadX() iomem argument (as in generic implementation)

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among

[PATCH v3 1/4] iomap: Constify ioreadX() iomem argument (as in generic implementation)

The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and

[PATCH v3 0/4] iomap: Constify ioreadX() iomem argument

Hi, Multiple architectures are affected in the first patch and all further patches depend on the first. Maybe this could go in through Andrew Morton's tree? Changes since v2 1. Drop all non-essential patches (cleanups), 2. Update also drivers/sh/clk/cpg.c . Changes since v1

RE: [PATCH 05/20] Documentation: fpga: eliminate duplicated word

> Subject: [PATCH 05/20] Documentation: fpga: eliminate duplicated word > > Drop the doubled word "this". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Wu Hao > Cc: linux-f...@vger.kernel.org Acked-by: Wu Hao Thanks Randy. Hao

Re: [PATCH v2 10/10] powerpc/perf: Add extended regs support for power10 platform

> On 08-Jul-2020, at 5:34 PM, Michael Ellerman wrote: > > Athira Rajeev > writes: >> Include capability flag `PERF_PMU_CAP_EXTENDED_REGS` for power10 >> and expose MMCR3, SIER2, SIER3 registers as part of extended regs. >> Also introduce

Re: [PATCH v2 3/3] misc: cxl: flash: Remove unused variable 'drc_index'

On 9/7/20 4:56 pm, Lee Jones wrote: Keeping the pointer increment though. Fixes the following W=1 kernel build warning: drivers/misc/cxl/flash.c: In function ‘update_devicetree’: drivers/misc/cxl/flash.c:178:16: warning: variable ‘drc_index’ set but not used [-Wunused-but-set-variable]

Re: [PATCH v2 3/5] powerpc/lib: Use a temporary mm for code patching

Le 09/07/2020 à 06:03, Christopher M. Riedl a écrit : Currently, code patching a STRICT_KERNEL_RWX exposes the temporary mappings to other CPUs. These mappings should be kept local to the CPU doing the patching. Use the pre-initialized temporary mm and patching address for this purpose. Also

[PATCH v2 3/3] misc: cxl: flash: Remove unused variable 'drc_index'

Keeping the pointer increment though. Fixes the following W=1 kernel build warning: drivers/misc/cxl/flash.c: In function ‘update_devicetree’: drivers/misc/cxl/flash.c:178:16: warning: variable ‘drc_index’ set but not used [-Wunused-but-set-variable] 178 | __be32 *data, drc_index, phandle;

[mm/debug_vm_pgtable] a97a171093: BUG:unable_to_handle_page_fault_for_address

Greeting, FYI, we noticed the following commit (built with gcc-9): commit: a97a17109332c3a9e361553adfa383c1e5205f3b ("[PATCH V4 2/4] mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers") url:

  1   2   >