All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: linux-riscv@lists.infradead.org, palmer@dabbelt.com
Cc: vineetg@rivosinc.com, bjorn@kernel.org, greentime.hu@sifive.com,
	paul.walmsley@sifive.com, guoren@linux.alibaba.com,
	anup@brainfault.org, atishp@atishpatra.org,
	heiko.stuebner@vrull.eu, Andy Chiu <andy.chiu@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Andy Chiu <andy.chiu@sifive.com>
Subject: Re: [v1, 0/6] riscv: support kernel-mode Vector
Date: Sun, 16 Jul 2023 11:26:03 +0200	[thread overview]
Message-ID: <4216859.NG923GbCHz@phil> (raw)
In-Reply-To: <20230715150032.6917-1-andy.chiu@sifive.com>

Am Samstag, 15. Juli 2023, 17:00:26 CEST schrieb Andy Chiu:
> This series provides support for running Vector code in kernel mode. The
> implementation is based on the v12 series of the Vector series, but with
> some additions. First, we introduce a mechanism to defer restoring
> Vector context for userspace programs (patch 1). This is similar to
> arm64 and x86's approaches when dealing with extra userspace register
> context. And it is benefitial to both Vector in user and kernel-mode.
> Then, patch 2, 3 add the kernel-mode Vector patch from v12 with minor
> modifications. At the end of the series, patch 4, 5, 6 add supports for
> making kernel-mode Vector code preemptible. We do this by adding
> kernel-mode Vector context, and keeping track of the frame where V
> context is last valid. We believe that enabling preemption of running V
> is a critical path for getting V more generally available in the
> kernel-mode. Besides, with status.VS, we can easily tell if
> saving/restoring V is required. This reduce the level of cost when
> running SIMD in kernel mode as compared to other arches. Other arches
> usually do not have a way to tell if extra context is dirty. Thus, if
> they also want to support running preemptible code with extra registers,
> then they must save/restore extra context at each context switch even if
> registers are not dirty.
> 
> The series is tested by loading a kernel module on a preemptive kernel.
> The module launches multiple kworkers which run Vector operations and
> verifies with scalar code. Also, the module provides userspace intefaces
> via fops to verify if we can run Vector code on syscall path.
> 
> Changes from the vector v12 series (for patch 2, 3):
>  - return a failure code when kernel_rvv_begin() fails.
>  - Do not immediately restore user's V context.

This works nicely with my vector crypto patchset rebased on
top of it:

Tested-by: Heiko Stuebner <heiko@sntech.de>



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

      parent reply	other threads:[~2023-07-16  9:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 15:00 [v1, 0/6] riscv: support kernel-mode Vector Andy Chiu
2023-07-15 15:00 ` [v1, 1/6] riscv: sched: defer restoring Vector context for user Andy Chiu
2023-07-17  9:46   ` Conor Dooley
2023-07-17 16:03     ` Andy Chiu
2023-07-15 15:00 ` [v1, 2/6] riscv: Add support for kernel mode vector Andy Chiu
2023-07-17 10:22   ` Conor Dooley
2023-07-20 14:54     ` Andy Chiu
2023-07-15 15:00 ` [v1, 3/6] riscv: Add vector extension XOR implementation Andy Chiu
2023-07-17 10:25   ` Conor Dooley
2023-07-20 14:56     ` Andy Chiu
2023-07-15 15:00 ` [v1, 4/6] riscv: vector: do not pass task_struct into riscv_v_vstate_{save,restore}() Andy Chiu
2023-07-17 10:32   ` Conor Dooley
2023-07-20 14:59     ` Andy Chiu
2023-07-15 15:00 ` [v1, 5/6] riscv: vector: allow kernel-mode Vector with preemption Andy Chiu
2023-07-17 11:05   ` Conor Dooley
2023-07-20 15:13     ` Andy Chiu
2023-07-15 15:00 ` [v1, 6/6] riscv: vector: enable preemptive kernel-mode Vector to be built Andy Chiu
2023-07-17 11:11   ` Conor Dooley
2023-07-16  9:26 ` Heiko Stuebner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4216859.NG923GbCHz@phil \
    --to=heiko@sntech.de \
    --cc=andy.chiu@sifive.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@atishpatra.org \
    --cc=bjorn@kernel.org \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@linux.alibaba.com \
    --cc=heiko.stuebner@vrull.eu \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=vineetg@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.