Message-Id: <7c531595-e987-422b-bcf7-48ad0ba49ce6@app.fastmail.com>
Date:   Wed, 04 Jan 2023 16:58:25 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Yann Sionneau" <ysionneau@...ray.eu>
Cc:     "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>,
        "Jules Maselbas" <jmaselbas@...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

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.

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?

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.

- 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.

    Arnd

Powered by blists - more mailing lists