* Re: [PATCH v5] ocxl: control via sysfs whether the FPGA is reloaded on a link reset
From: Michael Ellerman @ 2020-07-16 12:55 UTC (permalink / raw)
To: Frederic Barrat, ajd, linuxppc-dev, alastair, clombard
In-Reply-To: <20200619140439.153962-1-fbarrat@linux.ibm.com>
On Fri, 19 Jun 2020 16:04:39 +0200, Frederic Barrat wrote:
> Some opencapi FPGA images allow to control if the FPGA should be reloaded
> on the next adapter reset. If it is supported, the image specifies it
> through a Vendor Specific DVSEC in the config space of function 0.
Applied to powerpc/next.
[1/1] ocxl: control via sysfs whether the FPGA is reloaded on a link reset
https://git.kernel.org/powerpc/c/87db7579ebd5ded337056eb765542eb2608f16e3
cheers
^ permalink raw reply
* Re: [PATCH] ocxl: Replace HTTP links with HTTPS ones
From: Michael Ellerman @ 2020-07-16 12:55 UTC (permalink / raw)
To: linux-kernel, ajd, arnd, fbarrat, linuxppc-dev,
Alexander A. Klimov, gregkh
In-Reply-To: <20200713175506.36676-1-grandmaster@al2klimov.de>
On Mon, 13 Jul 2020 19:55:06 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
Applied to powerpc/next.
[1/1] ocxl: Replace HTTP links with HTTPS ones
https://git.kernel.org/powerpc/c/07497137a5efa9b2628c18083e8b07b33160153d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/Kconfig: Replace HTTP links with HTTPS ones
From: Michael Ellerman @ 2020-07-16 12:55 UTC (permalink / raw)
To: oss, linux-kernel, mpe, paulus, linuxppc-dev, Alexander A. Klimov,
benh
In-Reply-To: <20200713192656.37443-1-grandmaster@al2klimov.de>
On Mon, 13 Jul 2020 21:26:56 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
Applied to powerpc/next.
[1/1] powerpc/Kconfig: Replace HTTP links with HTTPS ones
https://git.kernel.org/powerpc/c/9a3e3dccbf4317d02d28f8f99a5d1ccce42f9922
cheers
^ permalink raw reply
* Re: [PATCH] cpuidle/powernv : Remove dead code block
From: Michael Ellerman @ 2020-07-16 12:55 UTC (permalink / raw)
To: Abhishek Goel, linux-kernel, linux-pm, linuxppc-dev
Cc: daniel.lezcano, rjw, ego
In-Reply-To: <20200706053258.121475-1-huntbag@linux.vnet.ibm.com>
On Mon, 6 Jul 2020 00:32:58 -0500, Abhishek Goel wrote:
> Commit 1961acad2f88559c2cdd2ef67c58c3627f1f6e54 removes usage of
> function "validate_dt_prop_sizes". This patch removes this unused
> function.
Applied to powerpc/next.
[1/1] cpuidle/powernv : Remove dead code block
https://git.kernel.org/powerpc/c/c339f9be304c21da1c42899a824f84a2cc9ced30
cheers
^ permalink raw reply
* Re: [PATCH v5 0/2] Add cpu hotplug support for powerpc/perf/hv-24x7
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Kajol Jain, mpe, linuxppc-dev; +Cc: nathanl, ego, suka, anju, maddy
In-Reply-To: <20200709051836.723765-1-kjain@linux.ibm.com>
On Thu, 9 Jul 2020 10:48:34 +0530, Kajol Jain wrote:
> This patchset add cpu hotplug support for hv_24x7 driver by adding
> online/offline cpu hotplug function. It also add sysfs file
> "cpumask" to expose current online cpu that can be used for
> hv_24x7 event count.
>
> Changelog:
> v4 -> v5
> - Since we are making PMU fail incase hotplug init failed, hence
> directly adding cpumask attr inside if_attrs rather then creating
> new attribute_group as suggested by Madhavan Srinivasan.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/perf/hv-24x7: Add cpu hotplug support
https://git.kernel.org/powerpc/c/1a8f0886a6008c98a926bdeca49f2ef33015a491
[2/2] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show cpumask
https://git.kernel.org/powerpc/c/792f73f747b82f6cb191a323e1f5755d33149b50
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Michael Ellerman, Nathan Chancellor
Cc: Geoff Levand, linux-kernel, clang-built-linux, Paul Mackerras,
Joel Stanley, linuxppc-dev
In-Reply-To: <20200624035920.835571-1-natechancellor@gmail.com>
On Tue, 23 Jun 2020 20:59:20 -0700, Nathan Chancellor wrote:
> Clang warns:
>
> arch/powerpc/boot/main.c:107:18: warning: array comparison always
> evaluates to a constant [-Wtautological-compare]
> if (_initrd_end > _initrd_start) {
> ^
> arch/powerpc/boot/main.c:155:20: warning: array comparison always
> evaluates to a constant [-Wtautological-compare]
> if (_esm_blob_end <= _esm_blob_start)
> ^
> 2 warnings generated.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot: Use address-of operator on section symbols
https://git.kernel.org/powerpc/c/df4232d96e724d09e54a623362f9f610727f059f
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/perf: Add kernel support for new MSR[HV PR] bits in trace-imc
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Madhavan Srinivasan, mpe; +Cc: Anju T Sudhakar, linuxppc-dev
In-Reply-To: <20200713144623.508695-1-maddy@linux.ibm.com>
On Mon, 13 Jul 2020 20:16:23 +0530, Madhavan Srinivasan wrote:
> IMC trace-mode record has MSR[HV PR] bits added in the third DW.
> These bits can be used to set the cpumode for the instruction pointer
> captured in each sample.
>
> Add support in kernel to use these bits to set the cpumode for
> each sample.
Applied to powerpc/next.
[1/1] powerpc/perf: Add kernel support for new MSR[HV PR] bits in trace-imc
https://git.kernel.org/powerpc/c/77ca3951cc37727ae8361d583a30da7a1b84e427
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/boot/dts: Fix dtc "pciex" warnings
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman; +Cc: sfr
In-Reply-To: <20200623130320.405852-1-mpe@ellerman.id.au>
On Tue, 23 Jun 2020 23:03:20 +1000, Michael Ellerman wrote:
> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
> warnings about our dts files, such as:
>
> arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
> Warning (pci_bridge): /plb/pciex@d00000000: node name is not "pci"
> or "pcie"
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot/dts: Fix dtc "pciex" warnings
https://git.kernel.org/powerpc/c/86bc917d2ac117ec922dbf8ed92ca989bf333281
cheers
^ permalink raw reply
* Re: [PATCH 00/18] remove extended cede offline mode and bogus topology update code
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: ego, svaidy, srikar, npiggin, tyreld
In-Reply-To: <20200612051238.1007764-1-nathanl@linux.ibm.com>
On Fri, 12 Jun 2020 00:12:20 -0500, Nathan Lynch wrote:
> Two major parts to this series:
>
> 1. Removal of the extended cede offline mode for CPUs as well as the
> partition suspend code which accommodates it by temporarily
> onlining all CPUs prior to suspending the LPAR. This solves some
> accounting problems, simplifies the pseries CPU hotplug code, and
> greatly uncomplicates the existing partition suspend code, easing
> a much-needed transition to the Linux suspend framework. The two
> patches which make up this part have been posted before:
>
> [...]
Applied to powerpc/next.
[01/18] powerpc/pseries: remove cede offline state for CPUs
https://git.kernel.org/powerpc/c/48f6e7f6d948b56489da027bc3284c709b939d28
[02/18] powerpc/rtas: don't online CPUs for partition suspend
https://git.kernel.org/powerpc/c/ec2fc2a9e9bbad9023aab65bc472ce7a3ca8608f
[03/18] powerpc/numa: remove ability to enable topology updates
https://git.kernel.org/powerpc/c/c30f931e891eb0a32885ecd79984e1e7366fceda
[04/18] powerpc/numa: remove unreachable topology update code
https://git.kernel.org/powerpc/c/7d35bef96a46f7e9e167bb25258c0bd389aeab1b
[05/18] powerpc/numa: make vphn_enabled, prrn_enabled flags const
https://git.kernel.org/powerpc/c/e6eacf8eb4dee7bc7021c837666e3ebf1b0ec3b5
[06/18] powerpc/numa: remove unreachable topology timer code
https://git.kernel.org/powerpc/c/50e0cf3742a01e72f4ea4a8fe9221b152e22871b
[07/18] powerpc/numa: remove unreachable topology workqueue code
https://git.kernel.org/powerpc/c/6325cb4a4ea8f4af8515b923650dd8f709694b44
[08/18] powerpc/numa: remove vphn_enabled and prrn_enabled internal flags
https://git.kernel.org/powerpc/c/9fb8b5fd1bf782a8257506ad5198237f4124d556
[09/18] powerpc/numa: stub out numa_update_cpu_topology()
https://git.kernel.org/powerpc/c/893ec6461f46c91487d914e6d467d2e804b9a883
[10/18] powerpc/numa: remove timed_topology_update()
https://git.kernel.org/powerpc/c/b1815aeac7fde2dc3412daf2efaededd21cd58e0
[11/18] powerpc/numa: remove start/stop_topology_update()
https://git.kernel.org/powerpc/c/1835303e5690cbeef2c07a9a5416045475ddaa13
[12/18] powerpc/rtasd: simplify handle_rtas_event(), emit message on events
https://git.kernel.org/powerpc/c/91713ac377859893a7798999cb2e3a388d8ae710
[13/18] powerpc/numa: remove prrn_is_enabled()
https://git.kernel.org/powerpc/c/042ef7cc43f4571d8cbe44a7c735ab6622809142
[14/18] powerpc/numa: remove arch_update_cpu_topology
https://git.kernel.org/powerpc/c/cdf082c4570f186d608aca688f2cc872b014558a
[15/18] powerpc/pseries: remove prrn special case from DT update path
https://git.kernel.org/powerpc/c/bb7c3d36e3b18aa02d34358ae75e1b91f69a968b
[16/18] powerpc/pseries: remove memory "re-add" implementation
https://git.kernel.org/powerpc/c/4abe60c6448bf1dba48689450ad1348e5fc6f7b7
[17/18] powerpc/pseries: remove dlpar_cpu_readd()
https://git.kernel.org/powerpc/c/38c392cef19019457ddcfb197ff3d9c5267698e6
[18/18] powerpc/pseries: remove obsolete memory hotplug DT notifier code
https://git.kernel.org/powerpc/c/e978a3ccaa714b5ff125857d2cbecbb6fdf6c094
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Alan Modra
In-Reply-To: <20200511101952.1463138-1-npiggin@gmail.com>
On Mon, 11 May 2020 20:19:52 +1000, Nicholas Piggin wrote:
> Returning from an interrupt or syscall to a signal handler currently
> begins execution directly at the handler's entry point, with LR set to
> the address of the sigreturn trampoline. When the signal handler
> function returns, it runs the trampoline. It looks like this:
>
> # interrupt at user address xyz
> # kernel stuff... signal is raised
> rfid
> # void handler(int sig)
> addis 2,12,.TOC.-.LCF0@ha
> addi 2,2,.TOC.-.LCF0@l
> mflr 0
> std 0,16(1)
> stdu 1,-96(1)
> # handler stuff
> ld 0,16(1)
> mtlr 0
> blr
> # __kernel_sigtramp_rt64
> addi r1,r1,__SIGNAL_FRAMESIZE
> li r0,__NR_rt_sigreturn
> sc
> # kernel executes rt_sigreturn
> rfid
> # back to user address xyz
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64/signal: Balance return predictor stack in signal trampoline
https://git.kernel.org/powerpc/c/0138ba5783ae0dcc799ad401a1e8ac8333790df9
cheers
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: branch cache flush changes
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200609070610.846703-1-npiggin@gmail.com>
On Tue, 9 Jun 2020 17:06:03 +1000, Nicholas Piggin wrote:
> This series allows the link stack to be flushed with the speical
> bcctr 2,0,0 flush instruction that also flushes the count cache if
> the processor supports it.
>
> Firmware does not support this at the moment, but I've tested it in
> simulator with a patched firmware to advertise support.
>
> [...]
Patches 1-6 applied to powerpc/next.
[1/7] powerpc/security: re-name count cache flush to branch cache flush
https://git.kernel.org/powerpc/c/1026798c644bfd3115fc4e32fd5e767cfc30ccf1
[2/7] powerpc/security: change link stack flush state to the flush type enum
https://git.kernel.org/powerpc/c/c06ac2771070f465076e87bba262c64fb0b3aca3
[3/7] powerpc/security: make display of branch cache flush more consistent
https://git.kernel.org/powerpc/c/1afe00c74ffe6d502bffa81c7d849cb4640d7ae5
[4/7] powerpc/security: split branch cache flush toggle from code patching
https://git.kernel.org/powerpc/c/c0036549a9d9a060fa8bc24e31f85503ce08ad5e
[5/7] powerpc/64s: Move branch cache flushing bcctr variant to ppc-ops.h
https://git.kernel.org/powerpc/c/70d7cdaf0548ec95fa7204dcdd39cd8e63cee24d
[6/7] powerpc/security: Allow for processors that flush the link stack using the special bcctr
https://git.kernel.org/powerpc/c/4d24e21cc694e7253a532fe5a9bde12b284f1317
cheers
^ permalink raw reply
* Re: [PATCH v3 0/3] selftests: powerpc: Fixes and execute-disable test for pkeys
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Sandipan Das, mpe
Cc: fweimer, aneesh.kumar, linuxram, linux-mm, linux-kselftest,
linuxppc-dev, bauerman
In-Reply-To: <20200604125610.649668-1-sandipan@linux.ibm.com>
On Thu, 4 Jun 2020 18:26:07 +0530, Sandipan Das wrote:
> This fixes the way the Authority Mask Register (AMR) is updated
> by the existing pkey tests and adds a new test to verify the
> functionality of execute-disabled pkeys.
>
> Previous versions can be found at:
> v2: https://lore.kernel.org/linuxppc-dev/20200527030342.13712-1-sandipan@linux.ibm.com/
> v1: https://lore.kernel.org/linuxppc-dev/20200508162332.65316-1-sandipan@linux.ibm.com/
>
> [...]
Applied to powerpc/next.
[1/3] selftests/powerpc: Fix pkey access right updates
https://git.kernel.org/powerpc/c/828ca4320d130bbe1d12866152600c49ff6a9f79
[2/3] selftests/powerpc: Move Hash MMU check to utilities
https://git.kernel.org/powerpc/c/c405b738daf9d8e8a5aedfeb6be851681e65e54b
[3/3] selftests/powerpc: Add test for execute-disabled pkeys
https://git.kernel.org/powerpc/c/1addb6444791f9e87fce0eb9882ec96a4a76e615
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries: detect secure and trusted boot state of the system.
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: linuxppc-dev, Nayna Jain; +Cc: linux-kernel, Mimi Zohar, Daniel Axtens
In-Reply-To: <1594813921-12425-1-git-send-email-nayna@linux.ibm.com>
On Wed, 15 Jul 2020 07:52:01 -0400, Nayna Jain wrote:
> The device-tree property to check secure and trusted boot state is
> different for guests(pseries) compared to baremetal(powernv).
>
> This patch updates the existing is_ppc_secureboot_enabled() and
> is_ppc_trustedboot_enabled() functions to add support for pseries.
>
> The secureboot and trustedboot state are exposed via device-tree property:
> /proc/device-tree/ibm,secure-boot and /proc/device-tree/ibm,trusted-boot
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pseries: Detect secure and trusted boot state of the system.
https://git.kernel.org/powerpc/c/61f879d97ce4510dd29d676a20d67692e3b34806
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: Make pnv_pci_sriov_enable() and friends static
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: kernel test robot
In-Reply-To: <20200705133557.443607-1-oohall@gmail.com>
On Sun, 5 Jul 2020 23:35:56 +1000, Oliver O'Halloran wrote:
> The kernel test robot noticed these are non-static which causes Clang to
> print some warnings. These are called via ppc_md function pointers so
> there's no need for them to be non-static.
Applied to powerpc/next.
[1/2] powerpc/powernv: Make pnv_pci_sriov_enable() and friends static
https://git.kernel.org/powerpc/c/93eacd94e09db2b1bb0343f8115385e5c34abf0a
[2/2] powerpc/powernv: Move pnv_ioda_setup_bus_dma under CONFIG_IOMMU_API
https://git.kernel.org/powerpc/c/e3417faec526cbf97773dca691dcd743f5bfeb64
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/64s: restore_math remove TM test
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Anton Blanchard, Gustavo Romero
In-Reply-To: <20200623234139.2262227-1-npiggin@gmail.com>
On Wed, 24 Jun 2020 09:41:37 +1000, Nicholas Piggin wrote:
> The TM test in restore_math added by commit dc16b553c949e ("powerpc:
> Always restore FPU/VEC/VSX if hardware transactional memory in use") is
> no longer necessary after commit a8318c13e79ba ("powerpc/tm: Fix
> restoring FP/VMX facility incorrectly on interrupts"), which removed
> the cases where restore_math has to restore if TM is active.
Applied to powerpc/next.
[1/3] powerpc/64s: restore_math remove TM test
https://git.kernel.org/powerpc/c/891b4fe8fe3d09f20948b391f24c9fc5b7580a2b
[2/3] powerpc/64s: Fix restore_math unnecessarily changing MSR
https://git.kernel.org/powerpc/c/01eb01877f3386d4bd5de75909abdd0af45a5fa2
[3/3] powerpc: re-initialise lazy FPU/VEC counters on every fault
https://git.kernel.org/powerpc/c/b2b46304e9360f3dda49c9d8ba4a1478b9eecf1d
cheers
^ permalink raw reply
* Re: [PATCH 1/1] MAINTAINERS: Remove self
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev
In-Reply-To: <aec7d729c28e35c7fa9969ec50229080c771195c.1593471043.git.sbobroff@linux.ibm.com>
On Tue, 30 Jun 2020 08:50:44 +1000, Sam Bobroff wrote:
> I'm sorry to say I can no longer maintain this position.
Applied to powerpc/next.
[1/1] MAINTAINERS: Remove self from powerpc EEH
https://git.kernel.org/powerpc/c/acccc984c1f2e49225b40f1d0d20d383ec27d4d0
cheers
^ permalink raw reply
* Re: [PATCH v6] powerpc/fadump: fix race between pstore write and fadump crash trigger
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: mpe, Sourabh Jain; +Cc: linuxppc-dev, linux-kernel, hbathini, mahesh
In-Reply-To: <20200713052435.183750-1-sourabhjain@linux.ibm.com>
On Mon, 13 Jul 2020 10:54:35 +0530, Sourabh Jain wrote:
> When we enter into fadump crash path via system reset we fail to update
> the pstore.
>
> On the system reset path we first update the pstore then we go for fadump
> crash. But the problem here is when all the CPUs try to get the pstore
> lock to initiate the pstore write, only one CPUs will acquire the lock
> and proceed with the pstore write. Since it in NMI context CPUs that fail
> to get lock do not wait for their turn to write to the pstore and simply
> proceed with the next operation which is fadump crash. One of the CPU who
> proceeded with fadump crash path triggers the crash and does not wait for
> the CPU who gets the pstore lock to complete the pstore update.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/fadump: fix race between pstore write and fadump crash trigger
https://git.kernel.org/powerpc/c/ba608c4fa12cfd0cab0e153249c29441f4dd3312
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc/xive: Remove unused inline function xive_kexec_teardown_cpu()
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: paulus, mpe, groug, benh, YueHaibing; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200715025040.33952-1-yuehaibing@huawei.com>
On Wed, 15 Jul 2020 10:50:40 +0800, YueHaibing wrote:
> commit e27e0a94651e ("powerpc/xive: Remove xive_kexec_teardown_cpu()")
> left behind this, remove it.
Applied to powerpc/next.
[1/1] powerpc/xive: Remove unused inline function xive_kexec_teardown_cpu()
https://git.kernel.org/powerpc/c/29d9407e1037868b59d12948d42ad3ef58fc3a5a
cheers
^ permalink raw reply
* Re: [PATCH -next] cpuidle/pseries: Make symbol 'pseries_idle_driver' static
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Hulk Robot, Wei Yongjun, Daniel Lezcano, Rafael J. Wysocki,
Michael Ellerman
Cc: linuxppc-dev, linux-pm
In-Reply-To: <20200714142424.66648-1-weiyongjun1@huawei.com>
On Tue, 14 Jul 2020 22:24:24 +0800, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/cpuidle/cpuidle-pseries.c:25:23: warning:
> symbol 'pseries_idle_driver' was not declared. Should it be static?
>
> 'pseries_idle_driver' is not used outside of this file, so marks
> it static.
Applied to powerpc/next.
[1/1] cpuidle/pseries: Make symbol 'pseries_idle_driver' static
https://git.kernel.org/powerpc/c/92fe8483b1660feaa602d8be6ca7efe95ae4789b
cheers
^ permalink raw reply
* Re: [PATCH 0/3] Implement shared_cpu_list for powerpc
From: Michael Ellerman @ 2020-07-16 12:56 UTC (permalink / raw)
To: Michael Ellerman, Srikar Dronamraju; +Cc: Nathan Lynch, linuxppc-dev
In-Reply-To: <20200629103703.4538-1-srikar@linux.vnet.ibm.com>
On Mon, 29 Jun 2020 16:07:00 +0530, Srikar Dronamraju wrote:
> shared_cpu_list sysfs file is missing in powerpc and shared_cpu_map gives an
> extra newline character.
>
> Before this patchset
> # ls /sys/devices/system/cpu0/cache/index1
> coherency_line_size number_of_sets size ways_of_associativity
> level shared_cpu_map type
> # cat /sys/devices/system/cpu0/cache/index1/shared_cpu_map
> 00ff
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/cacheinfo: Use cpumap_print to print cpumap
https://git.kernel.org/powerpc/c/5658cf085ba3c3f3c24ac0f7210f0473794df506
[2/3] powerpc/cacheinfo: Make cpumap_show code reusable
https://git.kernel.org/powerpc/c/74b7492e417812ea0f5002e210e2ac07a5728d17
[3/3] powerpc/cacheinfo: Add per cpu per index shared_cpu_list
https://git.kernel.org/powerpc/c/a87a77cb947cc9fc89f0dad51aeee66a61cc7fc4
cheers
^ permalink raw reply
* Re: [PATCH v3 0/4] powerpc/mm/radix: Memory unplug fixes
From: Nathan Lynch @ 2020-07-16 14:00 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Bharata B Rao
In-Reply-To: <20200709131925.922266-1-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> This is the next version of the fixes for memory unplug on radix.
> The issues and the fix are described in the actual patches.
I guess this isn't actually causing problems at runtime right now, but I
notice calls to resize_hpt_for_hotplug() from arch_add_memory() and
arch_remove_memory(), which ought to be mmu-agnostic:
int __ref arch_add_memory(int nid, u64 start, u64 size,
struct mhp_params *params)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int rc;
resize_hpt_for_hotplug(memblock_phys_mem_size());
start = (unsigned long)__va(start);
rc = create_section_mapping(start, start + size, nid,
params->pgprot);
...
^ permalink raw reply
* Re: [PATCH] pseries: Fix 64 bit logical memory block panic
From: Aneesh Kumar K.V @ 2020-07-16 14:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: nathanl, linuxppc-dev
In-Reply-To: <20200716013030.GA4076912@thinks.paulus.ozlabs.org>
On 7/16/20 7:00 AM, Paul Mackerras wrote:
> On Wed, Jul 15, 2020 at 06:12:25PM +0530, Aneesh Kumar K.V wrote:
>> Anton Blanchard <anton@ozlabs.org> writes:
>>
>>> Booting with a 4GB LMB size causes us to panic:
>>>
>>> qemu-system-ppc64: OS terminated: OS panic:
>>> Memory block size not suitable: 0x0
>>>
>>> Fix pseries_memory_block_size() to handle 64 bit LMBs.
>>>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Anton Blanchard <anton@ozlabs.org>
>>> ---
>>> arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> index 5ace2f9a277e..6574ac33e887 100644
>>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> @@ -27,7 +27,7 @@ static bool rtas_hp_event;
>>> unsigned long pseries_memory_block_size(void)
>>> {
>>> struct device_node *np;
>>> - unsigned int memblock_size = MIN_MEMORY_BLOCK_SIZE;
>>> + uint64_t memblock_size = MIN_MEMORY_BLOCK_SIZE;
>>> struct resource r;
>>>
>>> np = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>>
>> We need similar changes at more places?
>>
>> modified arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -85,7 +85,7 @@ extern unsigned int mmu_base_pid;
>> /*
>> * memory block size used with radix translation.
>> */
>> -extern unsigned int __ro_after_init radix_mem_block_size;
>> +extern unsigned long __ro_after_init radix_mem_block_size;
>>
>> #define PRTB_SIZE_SHIFT (mmu_pid_bits + 4)
>> #define PRTB_ENTRIES (1ul << mmu_pid_bits)
>> modified arch/powerpc/include/asm/drmem.h
>> @@ -21,7 +21,7 @@ struct drmem_lmb {
>> struct drmem_lmb_info {
>> struct drmem_lmb *lmbs;
>> int n_lmbs;
>> - u32 lmb_size;
>> + u64 lmb_size;
>> };
>>
>> extern struct drmem_lmb_info *drmem_info;
>> modified arch/powerpc/mm/book3s64/radix_pgtable.c
>> @@ -34,7 +34,7 @@
>>
>> unsigned int mmu_pid_bits;
>> unsigned int mmu_base_pid;
>> -unsigned int radix_mem_block_size __ro_after_init;
>> +unsigned long radix_mem_block_size __ro_after_init;
>
> These changes look fine.
>
>> static __ref void *early_alloc_pgtable(unsigned long size, int nid,
>> unsigned long region_start, unsigned long region_end)
>> modified arch/powerpc/mm/drmem.c
>> @@ -268,14 +268,15 @@ static void __init __walk_drmem_v2_lmbs(const __be32 *prop, const __be32 *usm,
>> void __init walk_drmem_lmbs_early(unsigned long node,
>> void (*func)(struct drmem_lmb *, const __be32 **))
>> {
>> + const __be64 *lmb_prop;
>> const __be32 *prop, *usm;
>> int len;
>>
>> - prop = of_get_flat_dt_prop(node, "ibm,lmb-size", &len);
>> - if (!prop || len < dt_root_size_cells * sizeof(__be32))
>> + lmb_prop = of_get_flat_dt_prop(node, "ibm,lmb-size", &len);
>> + if (!lmb_prop || len < sizeof(__be64))
>> return;
>>
>> - drmem_info->lmb_size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> + drmem_info->lmb_size = be64_to_cpup(lmb_prop);
>
> This particular change shouldn't be necessary. We already have
> dt_mem_next_cell() returning u64, and it knows how to combine two
> cells to give a u64 (for dt_root_size_cells == 2).
agreed. I added it here because in another patch i was confused about
the usage of dt_root_size_cells. We don't generally use that in other
device tree parsing code. I will move that to a separate patch as cleanup.
>
>> usm = of_get_flat_dt_prop(node, "linux,drconf-usable-memory", &len);
>>
>> @@ -296,19 +297,19 @@ void __init walk_drmem_lmbs_early(unsigned long node,
>>
>> static int __init init_drmem_lmb_size(struct device_node *dn)
>> {
>> - const __be32 *prop;
>> + const __be64 *prop;
>> int len;
>>
>> if (drmem_info->lmb_size)
>> return 0;
>>
>> prop = of_get_property(dn, "ibm,lmb-size", &len);
>> - if (!prop || len < dt_root_size_cells * sizeof(__be32)) {
>> + if (!prop || len < sizeof(__be64)) {
>> pr_info("Could not determine LMB size\n");
>> return -1;
>> }
>>
>> - drmem_info->lmb_size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> + drmem_info->lmb_size = be64_to_cpup(prop);
>
> Same comment here.
>
-aneesh
^ permalink raw reply
* Re: [PATCH V5 1/4] mm/debug_vm_pgtable: Add tests validating arch helpers for core MM features
From: Steven Price @ 2020-07-16 14:14 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Heiko Carstens, Paul Mackerras, H. Peter Anvin, agordeev,
Will Deacon, linux-riscv, linux-arch, linux-s390, x86,
Mike Rapoport, Christian Borntraeger, Ingo Molnar,
gerald.schaefer, ziy, Catalin Marinas, linux-snps-arc,
Vasily Gorbik, cai, Paul Walmsley, Kirill A . Shutemov,
Thomas Gleixner, linux-arm-kernel, christophe.leroy, Vineet Gupta,
linux-kernel, Palmer Dabbelt, aneesh.kumar, Borislav Petkov,
Andrew Morton, linuxppc-dev, rppt
In-Reply-To: <1594610587-4172-2-git-send-email-anshuman.khandual@arm.com>
On 13/07/2020 04:23, Anshuman Khandual wrote:
> This adds new tests validating arch page table helpers for these following
> core memory features. These tests create and test specific mapping types at
> various page table levels.
>
> 1. SPECIAL mapping
> 2. PROTNONE mapping
> 3. DEVMAP mapping
> 4. SOFTDIRTY mapping
> 5. SWAP mapping
> 6. MIGRATION mapping
> 7. HUGETLB mapping
> 8. THP mapping
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: x86@kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-arch@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Tested-by: Vineet Gupta <vgupta@synopsys.com> #arc
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> mm/debug_vm_pgtable.c | 302 +++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 301 insertions(+), 1 deletion(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index 61ab16fb2e36..2fac47db3eb7 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
[...]
> +
> +static void __init pte_swap_tests(unsigned long pfn, pgprot_t prot)
> +{
> + swp_entry_t swp;
> + pte_t pte;
> +
> + pte = pfn_pte(pfn, prot);
> + swp = __pte_to_swp_entry(pte);
Minor issue: this doesn't look necessarily valid - there's no reason a
normal PTE can be turned into a swp_entry. In practise this is likely to
work on all architectures because there's no reason not to use (at
least) all the PFN bits for the swap entry, but it doesn't exactly seem
correct.
Can we start with a swp_entry_t (from __swp_entry()) and check the round
trip of that?
It would also seem sensible to have a check that
is_swap_pte(__swp_entry_to_pte(__swp_entry(x,y))) is true.
> + pte = __swp_entry_to_pte(swp);
> + WARN_ON(pfn != pte_pfn(pte));
> +}
> +
> +#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> +static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot)
> +{
> + swp_entry_t swp;
> + pmd_t pmd;
> +
> + pmd = pfn_pmd(pfn, prot);
> + swp = __pmd_to_swp_entry(pmd);
> + pmd = __swp_entry_to_pmd(swp);
> + WARN_ON(pfn != pmd_pfn(pmd));
> +}
> +#else /* !CONFIG_ARCH_ENABLE_THP_MIGRATION */
> +static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot) { }
> +#endif /* CONFIG_ARCH_ENABLE_THP_MIGRATION */
> +
> +static void __init swap_migration_tests(void)
> +{
> + struct page *page;
> + swp_entry_t swp;
> +
> + if (!IS_ENABLED(CONFIG_MIGRATION))
> + return;
> + /*
> + * swap_migration_tests() requires a dedicated page as it needs to
> + * be locked before creating a migration entry from it. Locking the
> + * page that actually maps kernel text ('start_kernel') can be real
> + * problematic. Lets allocate a dedicated page explicitly for this
NIT: s/Lets/Let's
Otherwise looks good to me.
Steve
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Mathieu Desnoyers @ 2020-07-16 15:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-arch, Arnd Bergmann, x86, linux-kernel, Nicholas Piggin,
Andy Lutomirski, linux-mm, Andy Lutomirski, linuxppc-dev
In-Reply-To: <20200716110038.GA119549@hirez.programming.kicks-ass.net>
----- On Jul 16, 2020, at 7:00 AM, Peter Zijlstra peterz@infradead.org wrote:
> On Thu, Jul 16, 2020 at 08:03:36PM +1000, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 16, 2020 6:50 pm:
>> > On Wed, Jul 15, 2020 at 10:18:20PM -0700, Andy Lutomirski wrote:
>> >> > On Jul 15, 2020, at 9:15 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
>> >> But I’m wondering if all this deferred sync stuff is wrong. In the
>> >> brave new world of io_uring and such, perhaps kernel access matter
>> >> too. Heck, even:
>> >
>> > IIRC the membarrier SYNC_CORE use-case is about user-space
>> > self-modifying code.
>> >
>> > Userspace re-uses a text address and needs to SYNC_CORE before it can be
>> > sure the old text is forgotten. Nothing the kernel does matters there.
>> >
>> > I suppose the manpage could be more clear there.
>>
>> True, but memory ordering of kernel stores from kernel threads for
>> regular mem barrier is the concern here.
>>
>> Does io_uring update completion queue from kernel thread or interrupt,
>> for example? If it does, then membarrier will not order such stores
>> with user memory accesses.
>
> So we're talking about regular membarrier() then? Not the SYNC_CORE
> variant per-se.
>
> Even there, I'll argue we don't care, but perhaps Mathieu has a
> different opinion.
I agree with Peter that we don't care about accesses to user-space
memory performed concurrently with membarrier.
What we'd care about in terms of accesses to user-space memory from the
kernel is something that would be clearly ordered as happening before
or after the membarrier call, for instance a read(2) followed by
membarrier(2) after the read returns, or a read(2) issued after return
from membarrier(2). The other scenario we'd care about is with the compiler
barrier paired with membarrier: e.g. read(2) returns, compiler barrier,
followed by a store. Or load, compiler barrier, followed by write(2).
All those scenarios imply before/after ordering wrt either membarrier or
the compiler barrier. I notice that io_uring has a "completion" queue.
Let's try to come up with realistic usage scenarios.
So the dependency chain would be provided by e.g.:
* Infrequent read / Frequent write, communicating read completion through variable X
wait for io_uring read request completion -> membarrier -> store X=1
with matching
load from X (waiting for X==1) -> asm volatile (::: "memory") -> submit io_uring write request
or this other scenario:
* Frequent read / Infrequent write, communicating read completion through variable X
load from X (waiting for X==1) -> membarrier -> submit io_uring write request
with matching
wait for io_uring read request completion -> asm volatile (::: "memory") -> store X=1
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Mathieu Desnoyers @ 2020-07-16 15:46 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, Arnd Bergmann, Peter Zijlstra, x86, linux-kernel,
linux-mm, Andy Lutomirski, linuxppc-dev
In-Reply-To: <1594873644.viept6os6j.astroid@bobo.none>
----- On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npiggin@gmail.com wrote:
> I should be more complete here, especially since I was complaining
> about unclear barrier comment :)
>
>
> CPU0 CPU1
> a. user stuff 1. user stuff
> b. membarrier() 2. enter kernel
> c. smp_mb() 3. smp_mb__after_spinlock(); // in __schedule
> d. read rq->curr 4. rq->curr switched to kthread
> e. is kthread, skip IPI 5. switch_to kthread
> f. return to user 6. rq->curr switched to user thread
> g. user stuff 7. switch_to user thread
> 8. exit kernel
> 9. more user stuff
>
> What you're really ordering is a, g vs 1, 9 right?
>
> In other words, 9 must see a if it sees g, g must see 1 if it saw 9,
> etc.
>
> Userspace does not care where the barriers are exactly or what kernel
> memory accesses might be being ordered by them, so long as there is a
> mb somewhere between a and g, and 1 and 9. Right?
This is correct. Note that the accesses to user-space memory can be
done either by user-space code or kernel code, it doesn't matter.
However, in order to be considered as happening before/after
either membarrier or the matching compiler barrier, kernel code
needs to have causality relationship with user-space execution,
e.g. user-space does a system call, or returns from a system call.
In the case of io_uring, submitting a request or returning from waiting
on request completion appear to provide this causality relationship.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox