[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2331455.NG923GbCHz@diego>
Date: Fri, 20 Jan 2023 13:20:09 +0100
From: Heiko Stübner <heiko@...ech.de>
To: linux-riscv@...ts.infradead.org
Cc: Guo Ren <guoren@...ux.alibaba.com>,
Vincent Chen <vincent.chen@...ive.com>,
Han-Kuan Chen <hankuan.chen@...ive.com>,
Greentime Hu <greentime.hu@...ive.com>,
Palmer Dabbelt <palmer@...osinc.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Eric Biederman <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>,
Anup Patel <anup@...infault.org>,
Atish Patra <atishp@...shpatra.org>,
Oleg Nesterov <oleg@...hat.com>,
Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
Guo Ren <guoren@...nel.org>,
Chris Stillson <stillson@...osinc.com>,
Mayuresh Chitale <mchitale@...tanamicro.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Alexandre Ghiti <alexandre.ghiti@...onical.com>,
Qinglin Pan <panqinglin2020@...as.ac.cn>,
Arnd Bergmann <arnd@...db.de>,
Jisheng Zhang <jszhang@...nel.org>,
Dao Lu <daolu@...osinc.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Sunil V L <sunilvl@...tanamicro.com>,
Ruinland Tsai <ruinland.tsai@...ive.com>,
Li Zhengyu <lizhengyu3@...wei.com>,
Alexander Graf <graf@...zon.com>,
Ard Biesheuvel <ardb@...nel.org>,
Tsukasa OI <research_trasio@....a4lg.com>,
Yury Norov <yury.norov@...il.com>,
Nicolas Saenz Julienne <nsaenzju@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Frederic Weisbecker <frederic@...nel.org>,
Changbin Du <changbin.du@...el.com>,
Vitaly Wool <vitaly.wool@...sulko.com>,
Myrtle Shah <gatecat@....me>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Mark Brown <broonie@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Huacai Chen <chenhuacai@...nel.org>,
Janosch Frank <frankja@...ux.ibm.com>,
Christian Brauner <brauner@...nel.org>,
Peter Collingbourne <pcc@...gle.com>,
Eugene Syromiatnikov <esyr@...hat.com>,
Colin Cross <ccross@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Barret Rhoden <brho@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Davidlohr Bueso <dave@...olabs.net>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kvm@...r.kernel.org,
kvm-riscv@...ts.infradead.org,
Chris Stillson <stillson@...osinc.com>
Subject: Re: [PATCH v12 06/17] riscv: Reset vector register
Am Mittwoch, 21. September 2022, 23:43:48 CET schrieb Chris Stillson:
> @@ -431,6 +431,29 @@ ENTRY(reset_regs)
> csrw fcsr, 0
> /* note that the caller must clear SR_FS */
> #endif /* CONFIG_FPU */
> +
> +#ifdef CONFIG_VECTOR
> + csrr t0, CSR_MISA
> + li t1, COMPAT_HWCAP_ISA_V
> + and t0, t0, t1
> + beqz t0, .Lreset_regs_done
> +
> + /*
> + * Clear vector registers and reset vcsr
> + * VLMAX has a defined value, VLEN is a constant,
> + * and this form of vsetvli is defined to set vl to VLMAX.
> + */
> + li t1, SR_VS
> + csrs CSR_STATUS, t1
> + csrs CSR_VCSR, x0
> + vsetvli t1, x0, e8, m8, ta, ma
> + vmv.v.i v0, 0
> + vmv.v.i v8, 0
> + vmv.v.i v16, 0
> + vmv.v.i v24, 0
> + /* note that the caller must clear SR_VS */
> +#endif /* CONFIG_VECTOR */
> +
> .Lreset_regs_done:
Not sure how much they go together, but the #ifdef CONFIG_FPU block above
your new VECTOR block also jumps to the same .Lreset_regs_done, so with
the patch as is the vector-reset block is never reached in the !FPU case.
So maybe making them independent of each other might prevent issues
down the roead.
Powered by blists - more mailing lists