Le 11/02/2021 à 08:47, Gabriel Paubert a écrit :
On Thu, Feb 11, 2021 at 06:34:43AM +, Christophe Leroy wrote:
unrecoverable_exception() is never expected to return, most callers
have an infiniteloop in case it returns.
Ensure it really never returns by terminating it with a BUG(), and
d
Excerpts from Christophe Leroy's message of February 11, 2021 5:41 pm:
> powerpc BUG_ON() is based on using twnei or tdnei instruction,
> which obliges gcc to format the condition into a 0 or 1 value
> in a register.
>
> By using a generic implementation, gcc will generate a branch
> to the uncond
From: Kajol Jain
Thresholding, a performance monitoring unit feature, can be
used to identify marked instructions which take more than
expected cycles between start event and end event.
Threshold compare (thresh_cmp) bits are programmed in MMCRA
register. In Power9, thresh_cmp bits were part of t
As part of commit fbbefb320214 ("powerpc/pci: Move PHB discovery for
PCI_DN using platforms"), I switched some allocations from
memblock_alloc() to kmalloc(), otherwise memblock would warn that it
was being called after slab init.
However I missed that the code relied on the allocations being zero
On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
> powerpc BUG_ON() is based on using twnei or tdnei instruction,
> which obliges gcc to format the condition into a 0 or 1 value
> in a register.
Huh? Why is that?
Will it work better if this used __builtin_trap? Or does the kern
On Wed, Feb 10, 2021 at 8:05 PM Anders Roxell wrote:
>
> Since patch ("virtio-pci: introduce modern device module") got added it
> is not possible to boot a defconfig kernel in qemu with a virtio pci
> device. Add CONFIG_VIRTIO_PCI_MODERN=y fragment makes the kernel able
> to boot.
>
> Signed-off
On Thu, Feb 11, 2021 at 08:04:55PM +1000, Nicholas Piggin wrote:
> It would be nice if we could have a __builtin_trap_if that gcc would use
> conditional traps with, (and which never assumes following code is
> unreachable even for constant true, so we can use it with WARN and put
> explicit unr
> On 09-Feb-2021, at 6:17 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Wed, Feb 03, 2021 at 12:31:48PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Feb 02, 2021 at 04:02:36PM +0530, Athira Rajeev escreveu:
>>>
>>>
>>>On 18-Jan-2021, at 3:51 PM, kajoljain wrote:
>>>
>>>
>>>
>>>
Michael Ellerman writes:
> From: Kajol Jain
>
> Thresholding, a performance monitoring unit feature, can be
> used to identify marked instructions which take more than
> expected cycles between start event and end event.
> Threshold compare (thresh_cmp) bits are programmed in MMCRA
> register. In
On Thu, Feb 11, 2021 at 08:04:55PM +1000, Nicholas Piggin wrote:
> Excerpts from Christophe Leroy's message of February 11, 2021 5:41 pm:
> > As modern powerpc implement branch folding, that's even more efficient.
Ah, it seems you mean what Arm calls branch folding. Sure, power4
already did that,
Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :
On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
powerpc BUG_ON() is based on using twnei or tdnei instruction,
which obliges gcc to format the condition into a 0 or 1 value
in a register.
Huh? Why is that?
Will it work
On Thu, Feb 11, 2021 at 01:26:12PM +0100, Christophe Leroy wrote:
> >What PowerPC cpus implement branch folding? I know none.
>
> Extract from powerpc mpc8323 reference manual:
> — Zero-cycle branch capability (branch folding)
Yeah, this is not what is traditionally called branch folding (which
In hash__mark_rodata_ro() we pass the raw PP_RXXX value to
hash__change_memory_range(). That has the effect of setting the key to
zero, because PP_RXXX contains no key value.
Fix it by using htab_convert_pte_flags(), which knows how to convert a
pgprot into a pp value, including the key.
Fixes: d
In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
specific PAGE and PMD flags and definitions") and added definitions
for each MMU family.
However we missed adding a definition for 64s, which was not really a
The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes
the key in bits 9-13, but currently we always set those bits to zero.
In the past that hasn't been a problem because we always used key 0
for the kernel, and updateboltedpp() is only used for kernel mappings.
However since commi
Pull the loop calling hpte_updateboltedpp() out of
hash__change_memory_range() into a helper function. We need it to be a
separate function for the next patch.
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 23 +++
1 file changed, 15 insertions(
When we enabled STRICT_KERNEL_RWX we received some reports of boot
failures when using the Hash MMU and running under phyp. The crashes
are intermittent, and often exhibit as a completely unresponsive
system, or possibly an oops.
One example, which was caught in xmon:
[ 14.068327][T1] dev
We have now fixed the known bugs in STRICT_KERNEL_RWX for Book3S
64-bit Hash and Radix MMUs, see preceding commits, so allow the
option to be selected again.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/
Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :
On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
powerpc BUG_ON() is based on using twnei or tdnei instruction,
which obliges gcc to format the condition into a 0 or 1 value
in a register.
Huh? Why is that?
Will it work
On Thu, Feb 11, 2021 at 03:09:43PM +0100, Christophe Leroy wrote:
> Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :
> >On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
> >>powerpc BUG_ON() is based on using twnei or tdnei instruction,
> >>which obliges gcc to format the conditi
Le 11/02/2021 à 15:30, Segher Boessenkool a écrit :
On Thu, Feb 11, 2021 at 03:09:43PM +0100, Christophe Leroy wrote:
Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :
On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
powerpc BUG_ON() is based on using twnei or tdnei instr
tion
Date: Fri, 12 Feb 2021 00:50:20 +0800
From: kernel test robot
To: Lakshmi Ramasubramanian
CC: kbuild-...@lists.01.org
Hi Lakshmi,
I love your patch! Yet something to improve:
[auto build test ERROR on integrity/next-integrity]
[also build test ERROR on v5.11-rc7 next-20210211]
[cannot apply to
[also build test ERROR on v5.11-rc7 next-20210211]
[cannot apply to powerpc/next robh/for-next arm64/for-next/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-f
The pci_bus->bridge reference may no longer be valid after
pci_bus_remove() resulting in passing a bad value to device_unregister()
for the associated bridge device.
Store the host_bridge reference in a separate variable prior to
pci_bus_remove().
Fixes: 7340056567e3 ("powerpc/pci: Reorder pci bu
The H_FREE_SUB_CRQ hypercall can return a retry delay return code that
indicates the call needs to be retried after a specific amount of time
delay. The error path to free a sub-CRQ in case of a failure during
channel registration fails to capture the return code of H_FREE_SUB_CRQ
which will result
If ibmvfc_init_sub_crqs() fails ibmvfc_probe() simply parrots
registration failure reported elsewhere, and futher
vhost->scsi_scrq.scrq == NULL is indication enough to the driver that it
has no sub-CRQs available. The mq_enabled check can also be moved into
ibmvfc_init_sub_crqs() such that each cal
This series contains a minor simplification of ibmvfc_init_sub_crqs() followed
by a couple fixes for sub-CRQ handling which effect hard reset of the
client/host adapter CRQ pair.
A hard reset results in a complete transport disconnect such that the
CRQ connection with the partner VIOS is broken. This has the side effect
of also invalidating the associated sub-CRQs. The current code assumes
that the sub-CRQs are perserved resulting in a protocol violation after
trying to rec
A non-zero return code for H_REG_SUB_CRQ is currently treated as a
failure resulting in failing sub-CRQ setup. The case of H_CLOSED should
not be treated as a failure. This return code translates to a successful
sub-CRQ registration by the hypervisor, and is meant to communicate back
that there is
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerr
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop of_device_node
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank Rowand
Excerpts from Segher Boessenkool's message of February 11, 2021 9:50 pm:
> On Thu, Feb 11, 2021 at 08:04:55PM +1000, Nicholas Piggin wrote:
>> It would be nice if we could have a __builtin_trap_if that gcc would use
>> conditional traps with, (and which never assumes following code is
>> unreacha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull one final powerpc fix for 5.11:
The following changes since commit 24321ac668e452a4942598533d267805f291fdc9:
powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
(2021-02-02 22:14:41 +1100)
are availabl
Excerpts from Michael Ellerman's message of February 11, 2021 11:51 pm:
> When we enabled STRICT_KERNEL_RWX we received some reports of boot
> failures when using the Hash MMU and running under phyp. The crashes
> are intermittent, and often exhibit as a completely unresponsive
> system, or possibl
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop of_device_node
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerr
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank Rowand
The pull request you sent on Fri, 12 Feb 2021 10:15:59 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.11-8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dcc0b49040c70ad827a7f3d58a21b01fdb14e749
Thank you!
--
Deet-doot-d
Lakshmi Ramasubramanian writes:
> On 2/11/21 9:42 AM, Lakshmi Ramasubramanian wrote:
>> Hi Rob,
>> [PATCH] powerpc: Rename kexec elfcorehdr_addr to elf_headers_mem
>> This change causes build problem for x86_64 architecture (please see the
>> mail from kernel test bot below) since arch/x86/inc
On Tue, 2 Feb 2021 20:15:41 +1100, Alexey Kardashevskiy wrote:
> Since de78a9c "powerpc: Add a framework for Kernel Userspace Access
> Protection", user access helpers call user_{read|write}_access_{begin|end}
> when user space access is allowed.
>
> 890274c "powerpc/64s: Implement KUAP for Radix
On Thu, 4 Feb 2021 23:16:12 +1100, Alexey Kardashevskiy wrote:
> The amount of code executed with enabled user space access (unlocked KUAP)
> should be minimal. However with CONFIG_PROVE_LOCKING or
> CONFIG_DEBUG_ATOMIC_SLEEP enabled, might_fault() may end up replaying
> interrupts which in turn ma
On Wed, 3 Feb 2021 10:28:10 +0530, Aneesh Kumar K.V wrote:
> THP config results in compound pages. Make sure the kernel enables
> the PageCompound() check with CONFIG_HUGETLB_PAGE disabled and
> CONFIG_TRANSPARENT_HUGEPAGE enabled.
>
> This makes sure we correctly flush the icache with THP pages.
On Tue, 9 Feb 2021 10:26:21 + (UTC), Christophe Leroy wrote:
> get_tbl() is confusing as it returns the content TBL register
> on PPC32 but the concatenation of TBL and TBU on PPC64.
>
> Use mftb() instead.
>
> This will allow the removal of get_tbl() in a following patch.
Applied to powerpc
On Mon, 8 Feb 2021 07:17:40 + (UTC), Christophe Leroy wrote:
> THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
> Maximum PAGE_SHIFT is 18 for 256k pages so
> THREAD_ALIGN_SHIFT is 19 at the maximum.
>
> No need to clobber cr1, it can be preserved when moving r1
> into CR when we check s
On Mon, 8 Feb 2021 15:10:19 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's merge-test
> (b6f72fc05389e3fc694bf5a5fa1bbd33f61879e0)
>
> In terms on performance we have t
On Tue, 9 Feb 2021 14:02:12 + (UTC), Christophe Leroy wrote:
> Copied from commit 4b842e4e25b1 ("x86: get rid of small
> constant size cases in raw_copy_{to,from}_user()")
>
> Very few call sites where that would be triggered remain, and none
> of those is anywhere near hot enough to bother.
On Tue, 9 Feb 2021 19:29:26 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's next-test (f538b53fd47a) where main patchs
> from v5 are merged in.
>
> The first patch is im
On Thu, 04 Feb 2021 17:01:10 +0530, Hari Bathini wrote:
> On systems with large amount of memory, loading kdump kernel through
> kexec_file_load syscall may fail with the below error:
>
> "Failed to update fdt with linux,drconf-usable-memory property"
>
> This happens because the size estimat
On Sun, 7 Feb 2021 14:43:12 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./arch/powerpc/kvm/book3s_xive.c:1856:2-17: WARNING: Assignment of 0/1
> to bool variable.
>
> ./arch/powerpc/kvm/book3s_xive.c:1854:2-17: WARNING: Assignment of 0/1
> to bool variable.
Applied t
On Tue, 9 Feb 2021 15:22:34 +0530, Kajol Jain wrote:
> Thresholding, a performance monitoring unit feature, can be
> used to identify marked instructions which take more than
> expected cycles between start event and end event.
> Threshold compare (thresh_cmp) bits are programmed in MMCRA
> registe
On Thu, 11 Feb 2021 00:08:02 +1100, Michael Ellerman wrote:
> As reported by lkp:
>
> arch/powerpc/platforms/83xx/km83xx.c:183:19: error: 'mpc83xx_setup_pci'
> undeclared here (not in a function)
> 183 | .discover_phbs = mpc83xx_setup_pci,
>| ^
>
On Sat, 23 Jan 2021 16:15:04 +1000, Nicholas Piggin wrote:
> When replaying pending soft-masked interrupts when an interrupt returns
> to an irqs-enabled context, there is a special case required if this was
> an asynchronous interrupt to avoid unbounded interrupt recursion.
>
> This case was not
On Mon, 8 Feb 2021 16:34:06 +1000, Nicholas Piggin wrote:
> SLB faults should not be taken while the PACA save areas are live, all
> memory accesses should be fetches from the kernel text, and access to
> PACA and the current stack, before C code is called or any other
> accesses are made.
>
> All
On Mon, 8 Feb 2021 16:33:26 +1000, Nicholas Piggin wrote:
> Have the real mode system call entry handler branch to the kernel
> 0xc000... address and then use mtmsrd to enable the MMU, rather than use
> SRRs and rfid.
>
> Commit 8729c26e675c ("powerpc/64s/exception: Move real to virt switch
> into
On Thu, 11 Feb 2021 16:36:36 +1000, Nicholas Piggin wrote:
> The allyesconfig ppc64 kernel fails to link with relocations unable to
> fit after commit 3a96570ffceb ("powerpc: convert interrupt handlers to
> use wrappers"), which is due to the interrupt handler functions being
> put into the .noinst
On Wed, 2 Sep 2020 13:51:38 +1000, Oliver O'Halloran wrote:
> The corresponding definitions were deleted in commit 3d5134ee8341
> ("[POWERPC] Rewrite IO allocation & mapping on powerpc64") which
> was merged a mere 13 years ago.
Applied to powerpc/next.
[1/1] powerpc/pci: Remove unimplemented pro
Excerpts from Michael Ellerman's message of February 11, 2021 11:51 pm:
> When we enabled STRICT_KERNEL_RWX we received some reports of boot
> failures when using the Hash MMU and running under phyp. The crashes
> are intermittent, and often exhibit as a completely unresponsive
> system, or possibl
On 2/11/21 3:59 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
On 2/11/21 9:42 AM, Lakshmi Ramasubramanian wrote:
Hi Rob,
[PATCH] powerpc: Rename kexec elfcorehdr_addr to elf_headers_mem
This change causes build problem for x86_64 architecture (please see the
mail from kern
There's actually a complication that I just noticed and needs to be
addressed. More below.
Lakshmi Ramasubramanian writes:
> From: Rob Herring
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec. The differences are either omissions that arm64 should have
> or ad
On 2/11/21 5:09 PM, Thiago Jung Bauermann wrote:
There's actually a complication that I just noticed and needs to be
addressed. More below.
<...>
+
+/*
+ * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
+ *
+ * @image: kexec image being loaded.
+ * @i
The regular kernel stack can not be accessed in real mode in hash
guest kernels, which prevents the MMU from being disabled in general
C code. Provide a helper that can call a function pointer in real
mode using the emergency stack (accessable in real mode).
Signed-off-by: Nicholas Piggin
---
ar
Lakshmi Ramasubramanian writes:
> On 2/11/21 5:09 PM, Thiago Jung Bauermann wrote:
>> There's actually a complication that I just noticed and needs to be
>> addressed. More below.
>>
>
> <...>
>
>>> +
>>> +/*
>>> + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device
>>> Tr
Lakshmi Ramasubramanian writes:
> On 2/11/21 3:59 PM, Thiago Jung Bauermann wrote:
>> Lakshmi Ramasubramanian writes:
>>
>>> On 2/11/21 9:42 AM, Lakshmi Ramasubramanian wrote:
Hi Rob,
[PATCH] powerpc: Rename kexec elfcorehdr_addr to elf_headers_mem
This change causes build prob
On 2/11/21 6:11 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
On 2/11/21 3:59 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
On 2/11/21 9:42 AM, Lakshmi Ramasubramanian wrote:
Hi Rob,
[PATCH] powerpc: Rename kexec elfcorehdr_addr to elf_headers_mem
Th
Lakshmi Ramasubramanian writes:
> On 2/11/21 6:11 PM, Thiago Jung Bauermann wrote:
>> Lakshmi Ramasubramanian writes:
>>
>>> On 2/11/21 3:59 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
> On 2/11/21 9:42 AM, Lakshmi Ramasubramanian wrote:
>> Hi Rob,
Hi all,
Today's linux-next merge of the spi tree got a conflict in:
drivers/spi/spi-mpc52xx.c
between commit:
e10656114d32 ("spi: mpc52xx: Avoid using get_tbl()")
from the powerpc tree and commit:
258ea99fe25a ("spi: spi-mpc52xx: Use new structure for SPI transfer delays")
from the spi
Hi Chris,
(totally bikeshedding, but I'd use the full word parameter in the
subject if you have enough spare characters.)
> Unlike the other MSR_TM_* macros, MSR_TM_ACTIVE does not reference or
> use its parameter unless CONFIG_PPC_TRANSACTIONAL_MEM is defined. This
> causes an 'unused variable'
Hi Chris,
> Rework the messy ifdef breaking up the if-else for TM similar to
> commit f1cf4f93de2f ("powerpc/signal32: Remove ifdefery in middle of
> if/else").
I'm not sure what 'the messy ifdef' and 'the if-else for TM' is (yet):
perhaps you could start the commit message with a tiny bit of
ba
Hi Chris,
> Previously setup_sigcontext() performed a costly KUAP switch on every
> uaccess operation. These repeated uaccess switches cause a significant
> drop in signal handling performance.
>
> Rewrite setup_sigcontext() to assume that a userspace write access window
> is open. Replace all uac
On Thu, Feb 11, 2021 at 05:27:43PM -0600, Rob Herring wrote:
> This is a couple of cleanups for of_device.h. They fell out from my
> attempt at decoupling of_device.h and of_platform.h which is a mess
> and I haven't finished, but there's no reason to wait on these.
Reviewed-by: Greg Kroah-Hartman
71 matches
Mail list logo
