On Thu, Apr 27, 2023 at 11:09 AM Michael Ellerman wrote:
>
> Zhouyi Zhou writes:
> > On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote:
> >> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman
> >> wrote:
> ...
> >> >
> >> > There's 12.2.0 here:
> >> >
> >> >
Zhouyi Zhou writes:
> On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote:
>> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman wrote:
...
>> >
>> > There's 12.2.0 here:
>> >
>> > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/
>> >
>> >
successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alphabuildonly-randconfig-r001-20230426 gcc
alpha defconfig gcc
alpharandconfig-r012-20230426 gcc
arc
successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alphabuildonly-randconfig-r002-20230426 gcc
alpha defconfig gcc
arc allyesconfig gcc
arc
Defined CRYPTO_CHACHA20_P10 and CRYPTO POLY1305_P10 in Kconfig to
support optimized implementation for Power10 and later CPU.
Added new module driver chacha-p10-crypto and poly1305-p10-crypto.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/Kconfig | 26 ++
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/chacha-p10-glue.c | 221 ++
1 file changed, 221 insertions(+)
create mode 100644 arch/powerpc/crypto/chacha-p10-glue.c
diff --git a/arch/powerpc/crypto/chacha-p10-glue.c
b/arch/powerpc/crypto/chacha-p10-glue.c
new file
Improve overall performance of chacha20 encrypt and decrypt operations
for Power10 or later CPU.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
1 file changed, 842 insertions(+)
create mode 100644 arch/powerpc/crypto/chacha-p10le-8x.S
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/poly1305-p10-glue.c | 186
1 file changed, 186 insertions(+)
create mode 100644 arch/powerpc/crypto/poly1305-p10-glue.c
diff --git a/arch/powerpc/crypto/poly1305-p10-glue.c
b/arch/powerpc/crypto/poly1305-p10-glue.c
new
This patch series provide an accelerated/optimized Chacha20 and Poly1305
implementation for Power10 or later CPU (ppc64le). This module
implements algorithm specified in RFC7539. The implementation
provides 3.5X better performance than the baseline for Chacha20 and
Poly1305 individually and 1.5X
Improve overall performance of Poly1305 for Power10 or later CPU.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/poly1305-p10le_64.S | 1075 +++
1 file changed, 1075 insertions(+)
create mode 100644 arch/powerpc/crypto/poly1305-p10le_64.S
diff --git
On Mon, Mar 06, 2023 at 11:01:52AM -0800, David Matlack wrote:
> This series refactors the KVM stats macros to reduce duplication and
> adds the support for choosing custom names for stats.
>
> Custom name makes it possible to decouple the userspace-visible stat
> names from their internal
On Tue, Apr 25, 2023 at 10:59 PM Nicholas Piggin wrote:
>
> Suggested-by: Linus Torvalds
I was all "what is Nick talking about", and had to follow the link to
remember that old discussion at all.
Patch obviously looks fine to me, I'll presumably be getting it at
some future point as part of a
On 4/26/23 06:51, Vladimir Oltean wrote:
On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote:
The features which do not work (major protocol changes) are disabled :)
If it would cause this series to be immediately merged, I would remove
KX/KR and 2.5G which are the only untested link
Peter Zijlstra writes:
> On Wed, Apr 26, 2023 at 09:44:22AM -0400, Joel Fernandes wrote:
>
>> How could you control which code paths don't have the stack protector?
>> Just curious.
>
> https://lkml.kernel.org/r/20230412-no_stackp-v2-0-116f9fe4b...@google.com
We also have some entire files
On Wed, Apr 26, 2023 at 09:41:38AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 20, 2023 12:12 AM
> >
> > +static int iommu_init_driver(struct device *dev, const struct iommu_ops
> > *ops)
>
> would iommu_init_device() better fit the purpose?
Yeah.. that does
On Wed, Apr 26, 2023 at 09:44:22AM -0400, Joel Fernandes wrote:
> How could you control which code paths don't have the stack protector?
> Just curious.
https://lkml.kernel.org/r/20230412-no_stackp-v2-0-116f9fe4b...@google.com
On Thu, Apr 20, 2023 at 12:23:11PM +0800, Baolu Lu wrote:
> On 4/20/23 12:11 AM, Jason Gunthorpe wrote:
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index dbaf3ed9012c45..a82516c8ea87ad 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -569,7
On Wed, Apr 26, 2023 at 8:30 AM Michael Ellerman wrote:
>
> Joel Fernandes writes:
> > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
> ...
> >
> > Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> > canary? Michael, is this an optimization? Adding Christophe as well
> >
Joel Fernandes writes:
> On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
...
>
> Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> canary? Michael, is this an optimization? Adding Christophe as well
> since it came in a few years ago via the following commit:
I think
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change
On Mon, 20 Feb 2023 06:59:09 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This series removes support for four e300 (MPC83xx) Freescale processor
> family evaluation boards that were added to the kernel in the 2006 era.
>
> These boards
On Fri, 24 Feb 2023 15:49:56 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This series removes support for two PowerQUICC II (MPC82xx) Freescale
> processor family evaluation boards that were added to the kernel in
> approximately the 2003
On Sat, 25 Feb 2023 15:13:15 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This is the final series in reducing our day to day cost of carrying rare
> evaluation platforms. It targets the e600 Freescale processor family.
>
> It starts with
On Sat, 08 Apr 2023 16:01:09 +0200, Pali Rohár wrote:
> This patch series unifies all P2020 boards and machine descriptions into
> one generic unified P2020 machine description. With this generic machine
> description, kernel can boot on any P2020-based board with correct DTS
> file.
>
> Tested
On Sun, 09 Apr 2023 02:08:04 +0200, Pali Rohár wrote:
> This patch series contains cleanups for fsl_uli1575 driver.
>
> This patch series is prerequisite for another patch series:
> "powerpc/85xx: p2020: Create one unified machine description"
>
On Sat, 25 Mar 2023 22:28:56 +1000, Nicholas Piggin wrote:
> This series cleans up copy_thread and hopefully makes the code
> easier to understand. The big changes in patch 3 and 4 which use
> the switch stack instead of user int stack for restoring
> fn and args parameters for the new thread.
>
On Fri, 07 Apr 2023 14:09:24 +1000, Nicholas Piggin wrote:
> Use the preferred form of branch-and-link for finding the current
> address so objtool doesn't think it is an unannotated intra-function
> call.
>
>
Applied to powerpc/next.
[1/1] powerpc/boot: Fix crt0.S current address branch form
On Fri, 07 Apr 2023 14:09:09 +1000, Nicholas Piggin wrote:
> -mcpu=power10 will generate prefixed and pcrel code by default, which
> we do not support. The general kernel disables these with cflags, but
> those were missed for the boot wrapper.
>
>
Applied to powerpc/next.
[1/1] powerpc/boot:
On Wed, 26 Apr 2023 15:58:37 +1000, Nicholas Piggin wrote:
> This series is against powerpc next. The first two patches are
> independent build fixes for recent patches. Patches 3-5 separate
> boot Makefile BOOTCFLAGS and BOOTASFLAGS and stops passing some
> C code generation flags to the
On Sat, 08 Apr 2023 12:17:46 +1000, Nicholas Piggin wrote:
> This won't see a lot of real use until POWER10 is the oldest supported
> CPU for distros, but being as we're quite a unique user of toolchain I'd
> like to start ironing things out earlier rather than later. I'm making a
> list of
On Thu, 06 Apr 2023 10:51:30 -0700, Nathan Chancellor wrote:
> When building with W=1 after commit 80b6093b55e3 ("kbuild: add -Wundef
> to KBUILD_CPPFLAGS for W=1 builds"), the following warning occurs.
>
> In file included from arch/powerpc/kvm/bookehv_interrupts.S:26:
>
On Thu, 06 Apr 2023 22:21:18 +1000, Michael Ellerman wrote:
> check_return_regs_valid() is called from the middle of the irq exit
> handling, which is all notrace, so mark it notrace also.
>
>
Applied to powerpc/next.
[1/1] powerpc/irq: Mark check_return_regs_valid() notrace
On Tue, 11 Apr 2023 20:28:38 +1000, Michael Ellerman wrote:
> Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate
> corenet64_smp_defconfig and corenet32_smp_defconfig.
>
> That then allows both those configs to build kernels that boot in qemu
> using the ppce500 machine type
On Thu, 20 Apr 2023 15:21:49 +1000, Michael Ellerman wrote:
> Some powernv machines use IGB for networking, so build the driver in to
> enable net booting such machines.
>
>
Applied to powerpc/next.
[1/1] powerpc/configs/powernv: Add IGB=y
On Tue, 04 Apr 2023 20:28:47 +1000, Michael Ellerman wrote:
> The amdgpu driver builds some of its code with hard-float enabled,
> whereas the rest of the kernel is built with soft-float.
>
> When building with 64-bit long double, if soft-float and hard-float
> objects are linked together, the
On Fri, 24 Feb 2023 15:10:12 +1100, Andrew Donnellan wrote:
> Add a firmware feature flag, FW_FEATURE_PLPKS, to indicate availability of
> Platform KeyStore related hcalls.
>
> Check this flag in plpks_is_available() and pseries_plpks_init() before
> trying to make an hcall.
>
>
> [...]
On Wed, 29 Mar 2023 18:23:33 +1100, Michael Ellerman wrote:
> It's not necessary to prefix every command in archhelp with "@" (to
> supress echoing the command), because that is done by the top level
> Makefile when it evaluates archhelp.
>
>
Applied to powerpc/next.
[1/2] powerpc/Makefile:
On Thu, 20 Apr 2023 15:16:08 +1000, Michael Ellerman wrote:
> The ext4 code will mount ext2 filesystems, no need to build in both.
>
>
Applied to powerpc/next.
[1/2] powerpc/configs/64s: Use EXT4 to mount EXT2 filesystems
On Thu, 06 Apr 2023 14:33:13 +1000, Benjamin Gray wrote:
> The randomness based DSCR tests currently have a low probability of doing
> any writes to the DSCR, making them inefficient in uncovering bugs.
>
> This series adds lockstep variants to these RNG tests, to ensure the happy
> path is
On Fri, 07 Apr 2023 00:45:32 +1000, Michael Ellerman wrote:
> Code in the idle path is not allowed to be instrumented because RCU is
> disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
> noinstr/__cpuidle usage").
>
> Mark prep_irq_for_idle() __cpuidle, which is equivalent to
On Wed, 05 Apr 2023 14:23:16 +0930, Joel Stanley wrote:
> There are two copies of these defines. Keep the older ones as they have
> associated bit definitions.
>
>
Applied to powerpc/next.
[1/1] powerpc: Remove duplicate SPRN_HSRR definitions
On Fri, 14 Apr 2023 23:23:44 +1000, Michael Ellerman wrote:
> Update ppc64_defconfig to account for symbols moving around, no actual
> changes.
>
>
Applied to powerpc/next.
[01/32] powerpc/configs/64s: Update defconfig for symbol movement
On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote:
> The features which do not work (major protocol changes) are disabled :)
>
> If it would cause this series to be immediately merged, I would remove
> KX/KR and 2.5G which are the only untested link modes.
>
> That said, PCS support
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Have release fully clean up the iommu related parts of the struct device,
> no matter what state they are in.
>
> POWER creates iommu_groups without drivers attached, and the next patch
> removes the open-coding of this same
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> These are not used outside iommu.c, they should not be available to
> modular code.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> It makes logical sense that once the driver is attached to the device the
> sysfs links appear, even if we haven't fully created the group_device or
> attached the device to a domain.
>
> Fix the missing error handling on
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> +static int iommu_init_driver(struct device *dev, const struct iommu_ops
> *ops)
would iommu_init_device() better fit the purpose?
otherwise,
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Instead of returning the struct group_device and then later freeing it, do
> the entire free under the group->mutex and defer only putting the
> iommu_group.
>
> It is safe to remove the sysfs_links and free memory while
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is the only caller, and it doesn't need the generality of the
> function. We already know there is no iommu_group, so it is simply two
> function calls.
>
> Moving it here allows the following patches to split the logic
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> No reason to open code this, use the proper helper functions.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is a step toward making __iommu_probe_device() self contained.
>
> It should, under proper locking, check if the device is already associated
> with an iommu driver and resolve parallel probes. All but one of the
>
From: Danny Tsen
> Sent: 24 April 2023 19:47
>
> Improve overall performance of chacha20 encrypt and decrypt operations
> for Power10 or later CPU.
>
> Signed-off-by: Danny Tsen
> ---
> arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
> 1 file changed, 842 insertions(+)
On Fri, 2022-11-04 at 17:51 +, Christophe Leroy wrote:
>
>
> Le 04/11/2022 à 18:27, Andrew Donnellan a écrit :
> > When CONFIG_VMAP_STACK is enabled, we set THREAD_SIZE to be at
> > least the
> > size of a page.
> >
> > There's a few bits of assembly in the book3s64 code that use
> >
llvm-as does not recognise the pla mnemonic, which is used for pcrel
address generation. Use the equivalent paddi opcode instead. Clang
can not build working pcrel kernels yet, but this patch does allow it
to build a non-working pcrel kernel with llvm-as.
This could be unconditional or use a raw
GCC appears to have a bug where it generates immediate offsets beyond
the 16-bit range of d-form memory operations in extended inline asm
when prefix instructions are enabled. So simpler fallback asm is
implemented for CONFIG_PPC_KERNEL_PREFIXED builds for now.
Clang does not have this bug, so
x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from
KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it,
so that seems to be the way the world's going.
Compile performance building defconfig on a POWER10 PowerNV system
was in the noise after 10 builds
Tidy pass over boot Makefile. Move variables together where possible.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index
Tidy pass over boot Makefile. Move variables together where possible.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index
BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except
-pipe). Separate them to avoid fragility with cross-contamination of
flags which has caused several build problems.
Suggested-by: Linus Torvalds
Link:
Add BOOTCPPFLAGS variable for the CPP options required by C and AS.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index
Add BOOTTARGETFLAGS variable with target / ABI options common to
CFLAGS and AFLAGS.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 40 --
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/boot/Makefile
Clang has a bug that casues the pcrel code model not to be used when any of
-msoft-float, -mno-altivec, or -mno-vsx are set. Leaving these off causes
FP/vector instructions to be generated, causing crashes. So disable pcrel
for clang for now.
Signed-off-by: Nicholas Piggin
---
62 matches
Mail list logo
