On Wed, Dec 16, 2020 at 11:41 AM Michael Ellerman wrote:
>
> Masahiro Yamada writes:
> > On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman
> > wrote:
> >>
> >> The lkp robot reported that some configs fail to build, for example
> >> mpc85xx_smp_defconfig, with:
> >>
> >> cc1: fatal error:
Cédric Le Goater writes:
> On 12/11/20 12:51 AM, Michael Ellerman wrote:
>> Cédric Le Goater writes:
>>> PowerNV systems can handle up to 4K guests and 1M interrupt numbers
>>> per chip. Increase the range of allowed interrupts to support a larger
>>> number of guests.
>>>
>>> Reviewed-by: Greg
Masahiro Yamada writes:
> On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman wrote:
>>
>> The lkp robot reported that some configs fail to build, for example
>> mpc85xx_smp_defconfig, with:
>>
>> cc1: fatal error: opening output file
>> arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a003-20201215
x86_64 randconfig-a006-20201215
x86_64 randconfig-a002-20201215
x86_64
defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a003-20201215
x86_64 randconfig-a006
Excerpts from Alex Xu (Hello71)'s message of December 15, 2020 2:03 pm:
> bzip2 is either slower or larger than every other supported algorithm,
> according to benchmarks at [0]. It is far slower to decompress than any
> other algorithm, and still larger than lzma, xz, and zstd.
>
> [0]
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu
On Tue, Dec 15 2020 at 21:12, Enrico Weigelt wrote:
> On 09.12.20 00:01, Thomas Gleixner wrote:
>> 3) It's invoked from __handle_domain_irq() when the 'hwirq' which is
>> handed in by the caller does not resolve to a mapped Linux
>> interrupt which is pretty much the same as the x86
Hello,
On Tue, Dec 15, 2020 at 02:03:15PM -0500, Alex Xu (Hello71) wrote:
> bzip2 is either slower or larger than every other supported algorithm,
> according to benchmarks at [0]. It is far slower to decompress than any
> other algorithm, and still larger than lzma, xz, and zstd.
>
> [0]
On 09.12.20 00:01, Thomas Gleixner wrote:
> There are a few situations why it is invoked or not:
>
> 1) The original x86 usage is not longer using it because it complains
> rightfully about a vector being raised which has no interrupt
> descriptor associated to it. So the original
On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman wrote:
>
> The lkp robot reported that some configs fail to build, for example
> mpc85xx_smp_defconfig, with:
>
> cc1: fatal error: opening output file
> arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
>
> This
On 12/15/20 11:56 AM, Haren Myneni wrote:
> On Sat, 2020-12-12 at 15:27 +0100, Cédric Le Goater wrote:
>> The VAS device allocates a generic interrupt to handle page faults
>> but
>> the IRQ name doesn't show under /proc. This is because it's on
>> stack. Allocate the name.
>>
>> Signed-off-by:
On Sun, Dec 13, 2020 at 01:54:30AM +0900, Masahiro Yamada wrote:
> Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
> macros") introduced scripts/ld-version.sh for GCC LTO.
>
> At that time, this script handled 5 version fields because GCC LTO
> needed the downstream binutils.
On Fri, 27 Nov 2020 10:14:02 +0530, Aneesh Kumar K.V wrote:
> Don't enable KUEP/KUAP if we support less than or equal to 3 keys.
>
> [...]
Applied to powerpc/next.
[21/22] powerpc/book3s64/kup: Check max key supported before enabling kup
Michael Ellerman writes:
> On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
>> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
>> error reporting with KUAP") and update the fault handler to print
>>
>> [ 55.022514] Kernel attempted to access user page
On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
> attempt?
On Wed, 11 Nov 2020 21:07:20 +1000, Nicholas Piggin wrote:
> This conversion seems to require generic atomic64 changes, looks
> like nothing else uses ARCH_ATOMIC and GENERIC_ATOMIC64 yet.
>
> Thanks,
> Nick
>
> Nicholas Piggin (3):
> asm-generic/atomic64: Add support for ARCH_ATOMIC
>
On Wed, 9 Dec 2020 05:29:20 + (UTC), Christophe Leroy wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
>
On Sat, 2020-12-12 at 15:27 +0100, Cédric Le Goater wrote:
> The VAS device allocates a generic interrupt to handle page faults
> but
> the IRQ name doesn't show under /proc. This is because it's on
> stack. Allocate the name.
>
> Signed-off-by: Cédric Le Goater
Thanks for fixing.
Acked-by:
On Thu, 22 Oct 2020 06:29:26 + (UTC), Christophe Leroy wrote:
> On 8xx, we get the following features:
>
> [0.00] cpu_features = 0x0100
> [0.00] possible= 0x0120
> [0.00] always = 0x
>
> This is not
On Tue, 8 Dec 2020 13:54:34 -0600, Tyrel Datwyler wrote:
> Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
> introduced the following error when invoking the errinjct userspace
> tool.
>
> [root@ltcalpine2-lp5 librtas]# errinjct open
> [327884.071171] sys_rtas: RTAS
On Sun, 11 Oct 2020 10:39:03 +0530, Ravi Bangoria wrote:
> VSX vector paired instructions operates with octword (32-byte)
> operand for loads and stores between storage and a pair of two
> sequential Vector-Scalar Registers (VSRs). There are 4 word
> instructions and 2 prefixed instructions that
On Fri, 6 Nov 2020 10:26:50 +0530, Ravi Bangoria wrote:
> POWER10 DD1 has an issue where it generates watchpoint exceptions when
> it shouldn't. The conditions where this occur are:
>
> - octword op
> - ending address of DAWR range is less than starting address of op
> - those addresses need
On Sat, 7 Nov 2020 11:43:36 +1000, Nicholas Piggin wrote:
> This is way to catch some cases of decrementer overflow, when the
> decrementer has underflowed an odd number of times, while MSR[EE] was
> disabled.
>
> With a typical small decrementer, a timer that fires when MSR[EE] is
> disabled
On Fri, 6 Nov 2020 14:53:40 +1000, Nicholas Piggin wrote:
> No supported processor implements this mode. Setting the bit in
> MSR values can be a bit confusing (and would prevent the bit from
> ever being reused). Remove it.
Applied to powerpc/next.
[1/1] powerpc/64s: Remove MSR[ISF] bit
On Thu, 11 Jul 2019 12:24:03 +1000, Nicholas Piggin wrote:
> This implements the tricky tracing and soft irq handling bits in C,
> leaving the low level bit to asm.
>
> A functional difference is that this redirects the interrupt exit to
> a return stub to execute blr, rather than the lr address
On Mon, 7 Dec 2020 15:51:32 -0600, Nathan Lynch wrote:
> This series aims to improve the pseries-specific partition migration
> and hibernation implementation, part of which has been living in
> kernel/rtas.c. Most of that code is eliminated or moved to
> platforms/pseries, and the following major
On Thu, 10 Dec 2020 16:08:54 +0530, Gautham R. Shenoy wrote:
> This is the v2 of the patchset to extend parsing of "ibm,thread-groups"
> property
> to discover the Shared-L2 cache information.
>
> The previous versions can be found here :
>
> v2 :
>
On Mon, 7 Dec 2020 15:54:20 +, Colin King wrote:
> There is a spelling mistake in the help text of the Kconfig. Fix it.
Applied to powerpc/next.
[1/1] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected"
On Thu, 10 Dec 2020 18:14:37 +0100, Cédric Le Goater wrote:
> The most important change is the removal of support of OPAL flags
> required for P9 DD1. It provides a good cleanup of some complex
> routines.
>
> Thanks,
>
> C.
>
> [...]
Patches 1-3 and 5-13 applied to powerpc/next.
[01/13]
On Tue, 8 Dec 2020 05:24:19 + (UTC), Christophe Leroy wrote:
> low_sleep_handler() can't restore the context from standard
> stack because the stack can hardly be accessed with MMU OFF.
>
> Store everything in a global storage area instead of storing
> a pointer to the stack in that global
On Tue, 24 Nov 2020 15:24:54 + (UTC), Christophe Leroy wrote:
> Since commit e611939fc8ec ("powerpc/mm: Ensure change_page_attr()
> doesn't invalidate pinned TLBs"), pinned TLBs are not anymore
> invalidated by __kernel_map_pages() when CONFIG_DEBUG_PAGEALLOC is
> selected.
>
> Remove the
On Tue, 24 Nov 2020 19:51:55 + (UTC), Christophe Leroy wrote:
> primary_pteg_full and htab_hash_searches are not used.
>
> Remove them.
Applied to powerpc/next.
[1/3] powerpc/32s: Remove unused counters incremented by create_hpte()
On Fri, 4 Dec 2020 10:12:51 + (UTC), Christophe Leroy wrote:
> __set_dabr() are simple functions that can be inline directly
> inside set_dabr() and using IS_ENABLED() instead of #ifdef
Applied to powerpc/next.
[1/1] powerpc/process: Remove target specific __set_dabr()
On Fri, 6 Nov 2020 13:20:54 + (UTC), Christophe Leroy wrote:
> All hugetlb range freeing functions have a verification like the following,
> which only differs by the mask used, depending on the page table level.
>
> start &= MASK;
> if (start < floor)
> return;
>
On Fri, 4 Dec 2020 10:11:34 + (UTC), Christophe Leroy wrote:
> When SMC1 is relocated and early debug is selected, the
> board hangs is ppc_md.setup_arch(). This is because ones
> the microcode has been loaded and SMC1 relocated, early
> debug writes in the weed.
>
> To allow smooth
On Mon, 16 Nov 2020 16:09:31 + (UTC), Christophe Leroy wrote:
> On hash 32 bits, handling minor protection faults like unsetting
> dirty flag is heavy if done from the normal page_fault processing,
> because it implies hash table software lookup for flushing the entry
> and then a DSI is taken
On Wed, 25 Nov 2020 02:26:55 -0500, Athira Rajeev wrote:
> Perf event attritube supports exclude_kernel flag
> to avoid sampling/profiling in supervisor state (kernel).
> Based on this event attr flag, Monitor Mode Control Register
> bit is set to freeze on supervisor state. But sometime (due
> to
On Mon, 14 Dec 2020 13:31:21 +0530, Aneesh Kumar K.V wrote:
> The kernel call these functions on cpu online and hence they should
> not be marked __init.
Applied to powerpc/next.
[1/1] powerpc/64s: Mark the kuap/kuep functions non __init
Nicholas Piggin writes:
> Excerpts from Michael Ellerman's message of December 14, 2020 8:43 pm:
>> Nicholas Piggin writes:
>>> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
Hi Nicholas,
On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote:
>
Christophe Leroy writes:
> Le 15/12/2020 à 02:42, Michael Ellerman a écrit :
>> Christophe Leroy writes:
>>> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
it must not be __init, because it's used for CPU hotplug,
From: Madhavan Srinivasan
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
In Power10, this is a 8bit field, so patch fixes the
current code to
* Gautham R. Shenoy [2020-12-10 16:08:55]:
> From: "Gautham R. Shenoy"
>
> The "ibm,thread-groups" device-tree property is an array that is used
> to indicate if groups of threads within a core share certain
> properties. It provides details of which property is being shared by
> which groups
* Gautham R. Shenoy [2020-12-10 16:08:59]:
> From: "Gautham R. Shenoy"
>
> On POWER platforms where only some groups of threads within a core
> share the L2-cache (indicated by the ibm,thread-groups device-tree
> property), we currently print the incorrect shared_cpu_map/list for
> L2-cache in
* Gautham R. Shenoy [2020-12-10 16:08:58]:
> From: "Gautham R. Shenoy"
>
> On POWER systems, groups of threads within a core sharing the L2-cache
> can be indicated by the "ibm,thread-groups" property array with the
> identifier "2".
>
> This patch adds support for detecting this, and when
* Gautham R. Shenoy [2020-12-10 16:08:57]:
> From: "Gautham R. Shenoy"
>
> init_thread_group_l1_cache_map() initializes the per-cpu cpumask
> thread_group_l1_cache_map with the core-siblings which share L1 cache
> with the CPU. Make this function generic to the cache-property (L1 or
> L2) and
* Gautham R. Shenoy [2020-12-10 16:08:56]:
> From: "Gautham R. Shenoy"
>
> On platforms which have the "ibm,thread-groups" property, the per-cpu
> variable cpu_l1_cache_map keeps a track of which group of threads
> within the same core share the L1 cache, Instruction and Data flow.
>
> This
47 matches
Mail list logo