From: Conor Dooley <conor@kernel.org>
To: "Andrew Jones" <ajones@ventanamicro.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
kernel@esmil.dk, bjorn@kernel.org
Cc: "Heiko Stübner" <heiko@sntech.de>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Anup Patel" <anup@brainfault.org>,
"Atish Patra" <atishp@atishpatra.org>,
"Jisheng Zhang" <jszhang@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
"David Abdurachmanov" <david.abdurachmanov@gmail.com>
Subject: Re: [PATCH v3 05/13] riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions
Date: Thu, 19 Jan 2023 22:13:39 +0000 [thread overview]
Message-ID: <Y8nAk8c/acWf6++5@spud> (raw)
In-Reply-To: <20230119082903.yk3uslfrjtxzassi@orel>
[-- Attachment #1.1: Type: text/plain, Size: 3039 bytes --]
Me again!
On Thu, Jan 19, 2023 at 09:29:03AM +0100, Andrew Jones wrote:
> On Wed, Jan 18, 2023 at 09:54:46PM +0000, Conor Dooley wrote:
> > Hey!
> >
> > I guess here is the right place to follow up on all of this stuff...
> >
> > On Sat, Jan 14, 2023 at 08:32:37PM +0000, Conor Dooley wrote:
> > Today at [1] we talked a bit about the various bits going on here.
> > I'll attempt to summarise what I remember, but I meant to do this
> > several hours ago and am likely to make a hames of it.
> >
> > For Zbb/unaligned stuff, the sentiment was along the lines of there
> > needing to be a performance benefit to justify the inclusion.
> > Some of us have HW that is (allegedly) capable of Zbb, and, if that's the
I did some very very basic testing today. Ethernet is still a no-go on
my visionfive 2 board, but the sd card works at least, so I can run w/
Zbb code people want & we can see how it goes!
At the very least, it is capable of executing the instructions that were
used in Appendix A. I didn't try to do anything else, because I am lazy
and if there were some pre-existing test programs I didn't want to go
and write out a bunch of asm myself!
impid appears to be 0x4210427, if that means anything to anyone!
> > case, will give it a go.
> > I think it was similar for unaligned, since there is nothing yet that
> > supports this behaviour, we should wait until a benefit is demonstrable.
> >
> > On the subject of grouping extension/non-extension capabilities into a
> > single cpufeature, Palmer mentioned that GCC does something similar,
> > for the likes of the Ventana vendor extensions, that are unlikely to be
> > present in isolation.
Jess pointed out on IRC that GCC doesn't support XVentanaCondOps
so maybe there was a mixup there. I don't think that really matters
though, as the point stands regardless of whether it was in GCC or not.
> > Those are (or were?) probed as a group of extensions rather than
> > individually.
> > I think it was said it'd make sense for us to unify extensions that will
> > only ever appear together single psuedo cpufeature too.
> >
> > For the bitfield approach versus creating pseudo cpufeatures discussion
> > & how to deal with that in alternatives etc, I'm a bit less sure what the
> > outcome was.
> > IIRC, nothing concrete was said about either approach, but maybe it was
> > implied that we should do as GCC does, only grouping things that won't
> > ever been seen apart.
> > Figuring that out seems to have been punted down the road, as the
> > inclusion of our only current example of this (Zbb + unaligned) is
> > dependant on hardware showing up that actually benefits from it.
> >
> > The plan then seemed to be press ahead with this series & test the
> > benefits of the Zbb str* functions in Zbb capable hardware before making
> > a decision there.
> >
> > Hopefully I wasn't too far off with that summary...
>
> This matches my recollection. Thanks for the summary, Conor.
Cool, thanks.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-01-19 22:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 17:10 [PATCH v3 00/13] riscv: improve boot time isa extensions handling Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 01/13] riscv: fix jal offsets in patched alternatives Jisheng Zhang
2023-01-11 17:56 ` Andrew Jones
2023-01-11 23:31 ` Heiko Stübner
2023-01-12 20:25 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 02/13] riscv: move riscv_noncoherent_supported() out of ZICBOM probe Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 03/13] riscv: cpufeature: detect RISCV_ALTERNATIVES_EARLY_BOOT earlier Jisheng Zhang
2023-01-12 21:11 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 04/13] riscv: hwcap: make ISA extension ids can be used in asm Jisheng Zhang
2023-01-12 21:28 ` Conor Dooley
2023-01-15 13:13 ` Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 05/13] riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions Jisheng Zhang
2023-01-11 23:29 ` Heiko Stübner
2023-01-12 9:21 ` Andrew Jones
2023-01-13 15:18 ` Conor Dooley
2023-01-14 20:32 ` Conor Dooley
2023-01-18 21:54 ` Conor Dooley
2023-01-19 8:29 ` Andrew Jones
2023-01-19 22:13 ` Conor Dooley [this message]
2023-01-15 13:59 ` Jisheng Zhang
2023-01-15 14:19 ` Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 06/13] riscv: introduce riscv_has_extension_[un]likely() Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 07/13] riscv: fpu: switch has_fpu() to riscv_has_extension_likely() Jisheng Zhang
2023-01-12 21:58 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 08/13] riscv: module: move find_section to module.h Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 09/13] riscv: switch to relative alternative entries Jisheng Zhang
2023-01-11 18:11 ` Andrew Jones
2023-01-12 21:49 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 10/13] riscv: alternative: patch alternatives in the vDSO Jisheng Zhang
2023-01-11 23:55 ` kernel test robot
2023-01-12 7:48 ` Conor Dooley
2023-01-12 21:55 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 11/13] riscv: cpu_relax: switch to riscv_has_extension_likely() Jisheng Zhang
2023-01-12 21:59 ` Conor Dooley
2023-01-11 17:10 ` [PATCH v3 12/13] riscv: KVM: Switch has_svinval() to riscv_has_extension_unlikely() Jisheng Zhang
2023-01-11 17:10 ` [PATCH v3 13/13] riscv: remove riscv_isa_ext_keys[] array and related usage Jisheng Zhang
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=Y8nAk8c/acWf6++5@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=bjorn@kernel.org \
--cc=david.abdurachmanov@gmail.com \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=kernel@esmil.dk \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).