From: Conor Dooley <conor@kernel.org>
To: Alexandre Ghiti <alexghiti@rivosinc.com>
Cc: yunhui cui <cuiyunhui@bytedance.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Ved Shanbhogue <ved@rivosinc.com>, Matt Evans <mev@rivosinc.com>,
Dylan Jhong <dylan@andestech.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [External] [PATCH RFC/RFT v2 3/4] riscv: Stop emitting preventive sfence.vma for new vmalloc mappings
Date: Tue, 4 Jun 2024 09:51:55 +0100 [thread overview]
Message-ID: <20240604-dazzling-envy-1dcf111eb2c5@spud> (raw)
In-Reply-To: <CAHVXubg4vtfjSJ-w8-7suzZ9L5ZmTo8udUMaYjJ5veKBmikNjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Tue, Jun 04, 2024 at 09:17:26AM +0200, Alexandre Ghiti wrote:
> On Tue, Jun 4, 2024 at 9:15 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> > On Tue, Jun 4, 2024 at 8:21 AM yunhui cui <cuiyunhui@bytedance.com> wrote:
> > >
> > > As for the current status of the patch, there are two points that can
> > > be optimized:
> > > 1. Some chip hardware implementations may not cache TLB invalid
> > > entries, so it doesn't matter whether svvptc is available or not. Can
> > > we consider adding a CONFIG_RISCV_SVVPTC to control it?
>
> That would produce a non-portable kernel. But I'm not opposed to that
> at all, let me check how we handle other extensions. Maybe @Conor
> Dooley has some feedback here?
To be honest, not really sure what to give feedback on. Could you
elaborate on exactly what the option is going to do? Given the
portability concern, I guess you were proposing that the option would
remove the preventative fences, rather than your current patch that
removes them via an alternative? I don't think we have any extension
related options that work like that at the moment, and making that an
option will just mean that distros that look to cater for multiple
platforms won't be able to turn it on.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-06-04 8:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 15:59 [PATCH RFC v2 0/4] Svvptc extension to remove preventive sfence.vma Alexandre Ghiti
2024-01-31 15:59 ` [PATCH RFC/RFT v2 1/4] riscv: Add ISA extension parsing for Svvptc Alexandre Ghiti
2024-01-31 15:59 ` [PATCH RFC/RFT v2 2/4] dt-bindings: riscv: Add Svvptc ISA extension description Alexandre Ghiti
2024-02-01 9:22 ` Krzysztof Kozlowski
2024-01-31 15:59 ` [PATCH RFC/RFT v2 3/4] riscv: Stop emitting preventive sfence.vma for new vmalloc mappings Alexandre Ghiti
2024-06-03 2:26 ` [External] " yunhui cui
2024-06-03 12:02 ` Alexandre Ghiti
2024-06-04 6:21 ` yunhui cui
2024-06-04 7:15 ` Alexandre Ghiti
2024-06-04 7:17 ` Alexandre Ghiti
2024-06-04 8:51 ` Conor Dooley [this message]
2024-06-04 11:44 ` Alexandre Ghiti
2024-06-04 20:17 ` Conor Dooley
2024-01-31 15:59 ` [PATCH RFC/RFT v2 4/4] riscv: Stop emitting preventive sfence.vma for new userspace mappings with Svvptc Alexandre Ghiti
2024-02-01 15:03 ` Andrea Parri
2024-02-02 15:42 ` Alexandre Ghiti
2024-02-02 22:05 ` Alexandre Ghiti
2024-05-30 9:35 ` [External] " yunhui cui
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=20240604-dazzling-envy-1dcf111eb2c5@spud \
--to=conor@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=cuiyunhui@bytedance.com \
--cc=dylan@andestech.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mev@rivosinc.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=tsbogend@alpha.franken.de \
--cc=ved@rivosinc.com \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox