Message-ID: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu>
Date:   Thu, 5 Jan 2023 11:40:19 +0100
From:   Jules Maselbas <jmaselbas@...ray.eu>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Yann Sionneau <ysionneau@...ray.eu>,
        Albert Ou <aou@...s.berkeley.edu>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Aneesh Kumar <aneesh.kumar@...ux.ibm.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>, bpf@...r.kernel.org,
        Christian Brauner <brauner@...nel.org>,
        devicetree@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Eric Paris <eparis@...hat.com>, Ingo Molnar <mingo@...hat.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        Jason Baron <jbaron@...mai.com>, Jiri Olsa <jolsa@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Kieran Bingham <kbingham@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-audit@...hat.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-perf-users@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Marc Zyngier <maz@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Moore <paul@...l-moore.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Waiman Long <longman@...hat.com>,
        Will Deacon <will@...nel.org>, Alex Michon <amichon@...ray.eu>,
        Ashley Lesdalons <alesdalons@...ray.eu>,
        Benjamin Mugnier <mugnier.benjamin@...il.com>,
        Clement Leger <clement.leger@...tlin.com>,
        Guillaume Missonnier <gmissonnier@...ray.eu>,
        Guillaume Thouvenin <gthouvenin@...ray.eu>,
        Jean-Christophe Pince <jcpince@...il.com>,
        Jonathan Borne <jborne@...ray.eu>,
        Julian Vetter <jvetter@...ray.eu>,
        Julien Hascoet <jhascoet@...ray.eu>,
        Julien Villette <jvillette@...ray.eu>,
        Louis Morhet <lmorhet@...ray.eu>,
        Luc Michel <lmichel@...ray.eu>,
        Marc Poulhiès <dkm@...aplop.net>,
        Marius Gligor <mgligor@...ray.eu>,
        Samuel Jones <sjones@...ray.eu>,
        Thomas Costis <tcostis@...ray.eu>,
        Vincent Chardon <vincent.chardon@...ys-design.com>
Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port

Hi,

On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:
> > This patch series adds support for the kv3-1 CPU architecture of the kvx family
> > found in the Coolidge (aka MPPA3-80) SoC of Kalray.
> >
> > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils,
> > therefore this patch series cannot be merged into Linux for now.
> >
> > The goal is to have preliminary reviews and to fix problems early.
> >
> > The Kalray VLIW processor family (kvx) has the following features:
> > * 32/64 bits execution mode
> > * 6-issue VLIW architecture
> > * 64 x 64bits general purpose registers
> > * SIMD instructions
> > * little-endian
> > * deep learning co-processor
> 
> Thanks for posting these, I had been wondering about the
> state of the port. Overall this looks really nice, I can
> see that you and the team have looked at other ports
> and generally made the right decisions.

Thank you and all for the reviews. We are currently going
through every remarks and we are trying to do our best to
send a new patch series with everything addressed.

> I commented on the syscall patch directly, I think it's
> important to stop using the deprecated syscalls as soon
> as possible to avoid having dependencies in too many
> libc binaries. Almost everything else can be changed
> easily as you get closer to upstream inclusion.
> 
> I did not receive most of the other patches as I'm
> not subscribed to all the mainline lists. For future 
> submissions, can you add the linux-arch list to Cc for
> all patches?

We misused get_maintainers.pl, running it on each patch instead
of using it on the whole series. next time every one will be in
copy of every patch in the series and including linux-arch.

> Reading the rest of the series through lore.kernel.org,
> most of the comments I have are for improvements that
> you may find valuable rather than serious mistakes:
> 
> - the {copy_to,copy_from,clear}_user functions are
>   well worth optimizing better than the byte-at-a-time
>   version you have, even just a C version built around
>   your __get_user/__put_user inline asm should help, and
>   could be added to lib/usercopy.c.

right, we are using memcpy for {copy_to,copy_from}_user_page
which has a simple optimized version introduced in
(kvx: Add some library functions).
I wonder if it is possible to do the same for copy_*_user functions.

> - The __raw_{read,write}{b,w,l,q} helpers should
>   normally be defined as inline asm instead of
>   volatile pointer dereferences, I've seen cases where
>   the compiler ends up splitting the access or does
>   other things you may not want on MMIO areas.
>
> - I would recomment implementing HAVE_ARCH_VMAP_STACK
>   as well as IRQ stacks, both of these help to
>   avoid data corruption from stack overflow that you
>   will eventually run into.
> 
> - You use qspinlock as the only available spinlock
>   implementation, but only support running on a
>   single cluster of 16 cores. It may help to use
>   the generic ticket spinlock instead, or leave it
>   as a Kconfig option, in particular since you only
>   have the emulated xchg16() atomic for qspinlock.
> 
> - Your defconfig file enables CONFIG_EMBEDDED, which
>   in turn enables CONFIG_EXPERT. This is probably
>   not what you want, so better turn off both of these.
> 
> - The GENERIC_CALIBRATE_DELAY should not be necessary
>   since you have a get_cycles() based delay loop.
>   Just set loops_per_jiffy to the correct value based
>   on the frequency of the cycle counter, to save
>   a little time during boot and get a more accurate
>   delay loop.
>
Ack !

   Jules

Powered by blists - more mailing lists